This is AWESOME - Thanks! - Replies / comments embedded below... Paul Eggert wrote:
From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM
I am adding the POLYGON property targeted for the -01 version that has an ADD/DELETE parameter to allow for the optional inclusion of latitude/longitude geographic areas to be included that include (add) and exclude (delete) areas from the time zone geographic region (again from the CALSCH mailing list discussions).
It would be interesting to see a database containing some of that information, as a sample, as I don't offhand follow why DELETE would be useful.
In the past I was told that some time zones have geographic holes in them. And it was suggested by a cartographer in the CALSCH mailing list that it would make the data easier to use by them. As in if time-zone-x was surrounded entirely by time-zone-y. then time-zone-y has a hole in it. This data is optional and was simply on the list to make the cartographers happier. Maybe the names 'include' and 'exclude' should be used instead of 'add' and 'delete'.
Here are some comments on draft 00.
By creating an IANA registry, the same information will be available to any vendor. In addition there is revision control in the database so vendors will know if they have the latest data.
What process will be used to keep the IANA registry in sync with further changes to the TZ database? Here I am referring not only to changes in the data (e.g., Israel will probably change its rules again this year), but also the addition of new names, renaming entries, backwards compatibility for old names, etc.
There is an open source tool (vzic. I have a copy at http://INET-Consulting.com/vzic-1.2.tgz ) that converts the TZ database to iCalendar format. I have and will do more tweaks to adjust it for this specification. It can be run at any time.
Also, exactly which subset of tzdata will be used? Will the registry store only the rules that are compatible with the rules used today? (That's what the Boise example does, I think -- it omits DST rules in effect before 1987.) Or will the registry attempt to capture all the rules in tzdata?
The attempt will be to convert them all using the tweaked open source tool.
Will the registry use names that are not in tzdata? What general rules of thumb will the registry use to avoid collisions with new tzdata names in the future?
Straight conversion from the TZ database.
The "TZID" property values are broken down into three parts; region, city, and revision. And they are separated using the slash (/) character.
The tz database is not restricted to two-part names; in some of the more complicated cases like Indiana and Argentina, there are three-part names. Examples include America/Argentina/San_Juan and America/Indiana/Knox (the latter is given as an example in the "Initial Time Zone Names" section of draft 00). The TZID property values should therefore allow for an arbitrary number of parts of name.
Thanks - I did not notice that. I'll add optional "sub-regions"'s.
This example is using the America/Bosie time zone that was registered
Bosie -> Boise
The example data for Boise doesn't match what's in the TZ database. Is this intended? The example claims that the current rules have been in effect since 1970, whereas actually they have been in effect only since 1987.
When I ran VZIC I told it to start at 1970 so the sample would be short. I'll add the phrase 'factious example' to that example and change the name from Boise.
What constraints does the proposed specification place on the characters that can appear in TZID values, or in TZNAME values? Please see the Theory file in the tz database for its limits on TZID values (which are partly derived from portable POSIX file name restrictions); you can look under "Here are the general rules used for choosing location names". For restrictions on TZNAME values, plese see the "Time zone abbreviations" section in that file.
All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive.
Are TZID values case sensitive? I'm not a VTIMEZONE expert so it's hard for me to know.
By enumerated property values it is referring to predefined iCalendar names. The parameter AREA and its values ADD and DELETE are case insensitive. As are TZID and TZURL. Where ADD and DELETE are in the specification as enumerated values for AREA. TZID values are non-enumerated values. So TZID values are currently case sensitive UTF-8 characters. I have been told they can accommodate any known char-set. It can go ether way, what do you guys think it should be? Much if that text is from the iCalendar spec, I'll tweak it to be specific to this specification.
2.3 International Considerations
In the rest of this document, descriptions of characters are of the form "character name (codepoint)", where "codepoint" is from the US- ASCII character set.
I didn't see that notation used anywhere; perhaps this section is redundant?
I'll remove - thanks.
How would the registry handle alternate TZNAME values for different locales? Is there any plan for supporting "short names" or "long names" for zones? I suggest looking at the Time Zone Localization proposal, at:
http://oss.software.ibm.com/cvs/icu/~checkout~/locale/docs/design/formatting...
I will - thanks! The NAME property is being defined in iCalendar and it takes on the form: NAME:LANG=FR_ca:a name in French Canadian as an example. And multiple NAME properties are allowed per object . This I think should work for alternate names or aliases.
3. Security Considerations
There are no known security issues with this proposal as this is a repository of information and not an over the wire protocol.
If the repository becomes corrupted, any security-related enforcement that is based on local time (e.g., "you can access this site only from 9am-5pm local time") and which relies on the repository would become suspect.
If it becomes corrupt, it can be regenerate from scratch using the VZIC tool. I am not sure IANA wants every application that starts up to hit it for time zones changes. I would think that it might be a good idea to have a server. This proposal is for a repository or source if iCalendar time zone information, not a service. (Unless they say it is okay)
tzregion = "Africa" / "America" / "Asia" / "Europe" / "Indian" / "Pacific"
I would not hardwire the region names into the spec. For one thing, you missed some regions, e.g., "Atlantic". For another, the list of regions might change in the future.
Thanks!
8. Initial Time Zone Names
Is the intent of the registry to store aliases? For example, in the tz database, Europe/Vatican is an alias for Europe/Rome. You list both entries, so I assume the intent is to store some aliases. But you omit some other aliases so it's not clear to me what rules you're using to select a subset of the tz database's names.
Aliases - great idea (NAME above) If the draft becomes a registry, my plan is to put all of the current names in the registry.
Also, the initial names are a bit out of date: they use the old names for Argentine zones, and they lack the Europe/Mariehamn link for the Aaland Islands.
Another reference you should give is
Eggert, P. and Olson, A., "Sources for Time Zone and Daylight Saving Time Data" <http://www.twinsun.com/tz/tz-link.htm>, updated periodically.
Thanks again!
A point of terminology: Arthur David Olson is responsible for the code used to create and access the database, while I have maintained the data itself for many years, and have served as the editor for almost all the data that is currently present in it. So for the purpose of your proposal, the name "Olson database" is a bit of a misnomer, as you don't really care about the code or the existing database format; you care only about the data. I'd prefer it if you called it the "tz database" instead.
Great idea. His name was the point of contact when I first looked YEARS ago, and the name stuck. It will be changed to 'TZ database'. I asked Mr. Olson if he would like to co-author this specification to give it a more legitimize look. I offer you the same proposal. I'll do the editing and you can supply whatever you think is need in the spec. History, issues, problems, ... Yes/No/Maybe ? THANKS! -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards