Re: [calsify] Timezone Service Protocol not quite complete

[Cyrus Daboo <[e-mail]>]

Hi Steve, Julian,

--On November 7, 2013 at 10:55:18 AM -0400 Cyrus Daboo <[e-mail]> 
wrote:

> That said, one piece we have (deliberately) not defined in our diagram in
> Section 2 is how timezone data gets from "publishers" (e.g., IANA) to the
> top-level providers (right now most people ftp/http download the data
> package from IANA). That data is "static" and could quite easily be a put
> into the DNS after some appropriate re-packaging.

I note that it is probably not clear from our diagram and description in 
the spec that we are not trying to cover the "contributor" -> "publisher" 
-> top-level "provider" piece. That is something I will fix for the next 
revision of the spec.

--On November 7, 2013 at 10:46:12 AM -0500 Steve Crocker 
<[e-mail]> wrote:

> I haven't tried to work through the details yet but I would hope it
> should be reasonably straightforward to pack this data into something
> sensible within DNS and to choose an appropriate branch of the hierarchy.
> It could either get its own second level domain, e.g.
> "time-zone-data.org" or be published somewhere under iana.org.  I don't
> have any strong feelings about that as long as it's a domain name
> everyone can count on for the indefinite future.
>
> The slightly harder question is how to format this data for DNS.  I'll
> take a quick look to see what it looks like.

It is worth noting that there are several data formats in use right now:

- IANA package (the Olson data has "zone", "rule" and "link" data types 
which work together to define the rules for a single timezone)
- VTIMEZONE as defined by iCalendar (RFC5545)
- zoneinfo - used by most unix/linux-based systems for OS timezone data. 
This is typically generated from the IANA data
- Windows registry - Microsoft maintains its own independent set of 
timezones with data sourced internally, and typically stored in the Windows 
registry. We certainly should be able to support Microsoft as a "publisher".

Again, we deliberately did not address the "publisher" side of things 
because of the variety of options. However, our HTTP protocol does support 
content-negotiation via the "format" query parameter so it is possible to 
deliver timezone data in a variety of different formats in a fairly simple 
manner. We have already discussed the idea of writing a spec to formalize 
the zoneinfo format and give it a MIME type to make that possible. That is 
something we could do in conjunction with the IANA tz-database folks.

-- 
Cyrus Daboo