FW: IANA time zone registration - proposal

Doug Royer is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM To: tz@lecserver.nci.nih.gov Subject: IANA time zone registration - proposal [This was sent to some IETF mailing lists by me and someone suggested I send it to this list also] This is REV -00 of the proposal - comments welcome. Data in in it can easily updated. (Like the TZ names updated to latest copy of data) ---------------------------------------------------- A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF. A copy can be found at: http://inet-consulting.com/draft-royer-timezone-registry-00.txt And an HTML version: http://inet-consulting.com/draft-royer-timezone-registry-00.html 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). -- 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

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. 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. 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? 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?
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.
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. 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.
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? 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...
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.
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.
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. 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. 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.

On Mon, Jan 17, 2005 at 03:47:37PM -0800, 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.
Consider the imact of a region like America/Indiana/Knox on the polygon for America/New_York --- you need to subtract a polygon for the former out of the polygon for the latter in order to properly describe the geographic region encompassed by America/New_York. --Ken Pizzini

Doug Royer:
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).
The ADD/DELETE parameter will seem superfluous to anyone with a bit of background in computational geometry or computer graphics. Out-line font formats have well-established efficient ways of handling the problem of distinguishing between what is "inside" and "outside" a multi-polygon. For example, see the section "3.5 Direction of Paths" in Adobe Type 1 Font Format http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF Included polygons must be coded in counter-clockwise direction and excluded polygons clockwise. In other words, as you draw the boundary of the polygon, "inside" is always "left" of the pen direction, and "outside" is always "right". Couldn't be simpler. With such a path-direction convention in place, the ADD/DELETE parameter becomes redundant and most algorithms operating on such polygons become slightly simpler. However, standard polygon handling algorithms might need to be slightly adopted for spherical geometry, where, contrary to planar geometry, polygons may also go around the poles of the polar coordinate system used. Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__

Markus Kuhn said:
For example, see the section "3.5 Direction of Paths" in
Adobe Type 1 Font Format http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF
Included polygons must be coded in counter-clockwise direction and excluded polygons clockwise.
In other words, as you draw the boundary of the polygon, "inside" is always "left" of the pen direction, and "outside" is always "right". Couldn't be simpler.
Actually, there are two common algorithms in use. Draw a line-segment (needn't be straight, but must avoid any place the polygon intersects itself) from point P to somewhere at infinity (in practice, well outside the boundaries of the shape). (1) P is "inside" if the line-segment crosses the polygon an odd number of times. (2) For each crossing, determine whether the polygon is going left-to-right or right-to-left (when looking along the line-segment from P). P is "inside" if there are different numbers of crossings of each type. It looks like Adobe are using the second. However, I suspect the first will be better in this use. For an example of the difference, consider the shape: +---+ | | +---+---+---+ | | A | | | +---+---+ | | +-------+ In algorithm 1, area A is "outside". In algorithm 2, it is "inside". -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

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

Olson, Arthur David (NIH/NCI) said:
A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF.
A copy can be found at:
http://inet-consulting.com/draft-royer-timezone-registry-00.txt
Some brief comments. I'm not at all convinced that the iCalendar format is suitable. For example, it assumes that time zones only have two types of entry - "standard" and "daylight" (some zones also have "double summer time") - even if it does allow them to occur more than once. Furthermore, it is surely better to have the offset-change-moments specified in UTC than in some local timezone. The registry merely needs to contain the correct values. Fetching data from the registry and converting to a specific format is a software issue. The registry should either use the Olsen data directly, or it should use a clean, standard, and extensible format like XML. In section 5, <tzrev> should be specified as: tzrev = 8DIGIT "T" 6DIGIT "Z" except that I don't think being case-insensitive is a good idea, since ISO 8601 doesn't allow lowercase (IIRC). So it should be: tzrev = 8DIGIT %x54 6DIGIT %x5A Then explain that the digits are YYYYHHDD hhmmss in a separate comment. Or, if you prefer, write: tzrev = tzyear tzmon tzday %x54 tzhour tzmin tzsec %x5A tzyear = 4DIGIT tzmon = "0" %x31-39 / "10" / "11" / "12" tzday = ("0" / "1" / "2") DIGIT / "30" / "31" tzhour = ("0" / "1") DIGIT / "20" / "21" / "22" / "23" tzmin = %x30-35 DIGIT tzsec = %x30-35 DIGIT / "60" In section 6, shouldn't "rzrev" be "tzrev"? -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

I am quite leery about this project, having seen a number of other cases like this. The IANA charset registry, for example, is a real muddle; for example, some of the registered names are not compliant to the very specification they are supposed to be registered under, and there is nowhere near enough information in the registry to verify that the contents of a charset matches what is supposed to be registered. I'm not sure that people here realize the implications of this proposal. It means either that all the timezone database identifier updates have to funnel through the IANA process, or that the data will get out of sync, and people won't know which is authoritative; the registry or the database. While I do believe that it would be useful to have a more formal specification to answer certain issues that implementers need to depend on, at this point I would much rather see a single source. (And the proposed specification does not really add any information to what is already available.) Mark ----- Original Message ----- From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> To: "Tz (tz@elsie.nci.nih.gov)" <tz@lecserver.nci.nih.gov> Cc: <doug@royer.com> Sent: Monday, January 17, 2005 12:22 Subject: FW: IANA time zone registration - proposal
Doug Royer is not on the time zone mailing list; direct replies appropriately.
--ado
-----Original Message----- From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM To: tz@lecserver.nci.nih.gov Subject: IANA time zone registration - proposal
[This was sent to some IETF mailing lists by me and someone suggested I send it to this list also]
This is REV -00 of the proposal - comments welcome. Data in in it can easily updated. (Like the TZ names updated to latest copy of data)
---------------------------------------------------- A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF.
A copy can be found at:
http://inet-consulting.com/draft-royer-timezone-registry-00.txt
And an HTML version:
http://inet-consulting.com/draft-royer-timezone-registry-00.html
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).
--
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

Thank you. This is not a proposal for an authority. This is a proposal for an iCalendar repository that uses the IETF iCalendar format used by an increasing number of calendaring applications. Synching the data can be as simple as a few line cron (batch) job that runs at some interval. A tool already exists that converts from the current TZ format and stores the data in iCalendar format. This just keeps the now few hundred of calendar applications from having to compile in static versions. Now if they get an appointment in the FOO/FEE time zone, they can query a source and find it in a way that is compatible to the IETF iCalendar format. Currently all vendors have had to make static snapshots, compile it into their code and hope. Mark Davis wrote:
I am quite leery about this project, having seen a number of other cases like this. The IANA charset registry, for example, is a real muddle; for example, some of the registered names are not compliant to the very specification they are supposed to be registered under, and there is nowhere near enough information in the registry to verify that the contents of a charset matches what is supposed to be registered.
I'm not sure that people here realize the implications of this proposal. It means either that all the timezone database identifier updates have to funnel through the IANA process, or that the data will get out of sync, and people won't know which is authoritative; the registry or the database.
While I do believe that it would be useful to have a more formal specification to answer certain issues that implementers need to depend on, at this point I would much rather see a single source. (And the proposed specification does not really add any information to what is already available.)
Mark
----- Original Message ----- From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> To: "Tz (tz@elsie.nci.nih.gov)" <tz@lecserver.nci.nih.gov> Cc: <doug@royer.com> Sent: Monday, January 17, 2005 12:22 Subject: FW: IANA time zone registration - proposal
Doug Royer is not on the time zone mailing list; direct replies appropriately.
--ado
-----Original Message----- From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM To: tz@lecserver.nci.nih.gov Subject: IANA time zone registration - proposal
[This was sent to some IETF mailing lists by me and someone suggested I
send
it to this list also]
This is REV -00 of the proposal - comments welcome. Data in in it can
easily
updated. (Like the TZ names updated to latest copy of data)
---------------------------------------------------- A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF.
A copy can be found at:
http://inet-consulting.com/draft-royer-timezone-registry-00.txt
And an HTML version:
http://inet-consulting.com/draft-royer-timezone-registry-00.html
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).
--
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
-- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards

My apologies on this. I hadn't had time to respond when the original posting was made, and I mis-remembered the document. I still do have some concerns that the tzids will drift out of sync; and also how the stability of tzids will be handled. The stability issue is this. We've been advised to use zone.tab as the collection of valid names, with others being aliases. We do that, with the addition of the GMT{+/-number} items. The database is good about putting in links when one of those values changes, so that any old name remains as an alias. However, where we are working with a system of intercommunicating components, that may be released at different times, when component A uses a new name, it won't be able to that tzid to communicated with a component B that was built with the old name. So what we are doing for localization is that we are fixing the zone names as of a particular point, and any new names we will just treat as aliases, as in the attached list. That way once an identifier is introduced in zone.tab (after our start date), it stays stable from then on. How are you approaching stability of tzids with iCalendar? Or is that not an issue in that domain? Afghanistan (AF) tzid: Asia/Kabul Aland Islands (AX) tzid: Europe/Mariehamn Albania (AL) tzid: Europe/Tirane Algeria (DZ) tzid: Africa/Algiers American Samoa (AS) tzid: Pacific/Pago_Pago alias: Pacific/Samoa alias: US/Samoa Andorra (AD) tzid: Europe/Andorra Angola (AO) tzid: Africa/Luanda Anguilla (AI) tzid: America/Anguilla Antarctica (AQ) tzid: Antarctica/Casey tzid: Antarctica/Davis tzid: Antarctica/DumontDUrville tzid: Antarctica/Mawson tzid: Antarctica/McMurdo tzid: Antarctica/Palmer tzid: Antarctica/Rothera tzid: Antarctica/South_Pole tzid: Antarctica/Syowa tzid: Antarctica/Vostok Antigua and Barbuda (AG) tzid: America/Antigua Argentina (AR) tzid: America/Argentina/ComodRivadavia tzid: America/Argentina/La_Rioja tzid: America/Argentina/Rio_Gallegos tzid: America/Argentina/San_Juan tzid: America/Argentina/Tucuman tzid: America/Argentina/Ushuaia tzid: America/Buenos_Aires alias: America/Argentina/Buenos_Aires tzid: America/Catamarca alias: America/Argentina/Catamarca tzid: America/Cordoba alias: America/Argentina/Cordoba alias: America/Rosario tzid: America/Jujuy alias: America/Argentina/Jujuy tzid: America/Mendoza alias: America/Argentina/Mendoza Armenia (AM) tzid: Asia/Yerevan Aruba (AW) tzid: America/Aruba Australia (AU) tzid: Australia/Adelaide alias: Australia/South tzid: Australia/Brisbane alias: Australia/Queensland tzid: Australia/Broken_Hill alias: Australia/Yancowinna tzid: Australia/Darwin alias: Australia/North tzid: Australia/Hobart alias: Australia/Tasmania tzid: Australia/Lindeman tzid: Australia/Lord_Howe alias: Australia/LHI tzid: Australia/Melbourne alias: Australia/Victoria tzid: Australia/Perth alias: Australia/West tzid: Australia/Sydney alias: Australia/ACT alias: Australia/Canberra alias: Australia/NSW Austria (AT) tzid: Europe/Vienna Azerbaijan (AZ) tzid: Asia/Baku Bahamas (BS) tzid: America/Nassau Bahrain (BH) tzid: Asia/Bahrain Bangladesh (BD) tzid: Asia/Dhaka alias: Asia/Dacca Barbados (BB) tzid: America/Barbados Belarus (BY) tzid: Europe/Minsk Belgium (BE) tzid: Europe/Brussels Belize (BZ) tzid: America/Belize Benin (BJ) tzid: Africa/Porto-Novo Bermuda (BM) tzid: Atlantic/Bermuda Bhutan (BT) tzid: Asia/Thimphu alias: Asia/Thimbu Bolivia (BO) tzid: America/La_Paz Bosnia and Herzegovina (BA) tzid: Europe/Sarajevo Botswana (BW) tzid: Africa/Gaborone Brazil (BR) tzid: America/Araguaina tzid: America/Bahia tzid: America/Belem tzid: America/Boa_Vista tzid: America/Campo_Grande tzid: America/Cuiaba tzid: America/Eirunepe tzid: America/Fortaleza tzid: America/Maceio tzid: America/Manaus alias: Brazil/West tzid: America/Noronha alias: Brazil/DeNoronha tzid: America/Porto_Velho tzid: America/Recife tzid: America/Rio_Branco alias: America/Porto_Acre alias: Brazil/Acre tzid: America/Sao_Paulo alias: Brazil/East British Indian Ocean Territory (IO) tzid: Indian/Chagos British Virgin Islands (VG) tzid: America/Tortola Brunei (BN) tzid: Asia/Brunei Bulgaria (BG) tzid: Europe/Sofia Burkina Faso (BF) tzid: Africa/Ouagadougou Burundi (BI) tzid: Africa/Bujumbura Cambodia (KH) tzid: Asia/Phnom_Penh Cameroon (CM) tzid: Africa/Douala Canada (CA) tzid: America/Cambridge_Bay tzid: America/Dawson tzid: America/Dawson_Creek tzid: America/Edmonton alias: Canada/Mountain tzid: America/Glace_Bay tzid: America/Goose_Bay tzid: America/Halifax alias: Canada/Atlantic alias: SystemV/AST4ADT tzid: America/Inuvik tzid: America/Iqaluit tzid: America/Montreal tzid: America/Nipigon tzid: America/Pangnirtung tzid: America/Rainy_River tzid: America/Rankin_Inlet tzid: America/Regina alias: Canada/East-Saskatchewan alias: Canada/Saskatchewan alias: SystemV/CST6 tzid: America/St_Johns alias: Canada/Newfoundland tzid: America/Swift_Current tzid: America/Thunder_Bay tzid: America/Toronto alias: Canada/Eastern tzid: America/Vancouver alias: Canada/Pacific tzid: America/Whitehorse alias: Canada/Yukon tzid: America/Winnipeg alias: Canada/Central tzid: America/Yellowknife Cape Verde (CV) tzid: Atlantic/Cape_Verde Cayman Islands (KY) tzid: America/Cayman Central African Republic (CF) tzid: Africa/Bangui Chad (TD) tzid: Africa/Ndjamena Chile (CL) tzid: America/Santiago alias: Chile/Continental tzid: Pacific/Easter alias: Chile/EasterIsland China (CN) tzid: Asia/Chongqing alias: Asia/Chungking tzid: Asia/Harbin tzid: Asia/Kashgar tzid: Asia/Shanghai alias: PRC tzid: Asia/Urumqi Christmas Island (CX) tzid: Indian/Christmas Cocos (Keeling) Islands (CC) tzid: Indian/Cocos Colombia (CO) tzid: America/Bogota Comoros (KM) tzid: Indian/Comoro Congo (CG) tzid: Africa/Brazzaville Cook Islands (CK) tzid: Pacific/Rarotonga Costa Rica (CR) tzid: America/Costa_Rica Côte d’Ivoire (CI) tzid: Africa/Abidjan Croatia (HR) tzid: Europe/Zagreb Cuba (CU) tzid: America/Havana alias: Cuba Cyprus (CY) tzid: Asia/Nicosia alias: Europe/Nicosia Czech Republic (CZ) tzid: Europe/Prague Czechoslovakia (CS) tzid: Europe/Belgrade Democratic Republic of the Congo (CD) tzid: Africa/Kinshasa tzid: Africa/Lubumbashi Denmark (DK) tzid: Europe/Copenhagen Djibouti (DJ) tzid: Africa/Djibouti Dominica (DM) tzid: America/Dominica Dominican Republic (DO) tzid: America/Santo_Domingo Ecuador (EC) tzid: America/Guayaquil tzid: Pacific/Galapagos Egypt (EG) tzid: Africa/Cairo alias: Egypt El Salvador (SV) tzid: America/El_Salvador Equatorial Guinea (GQ) tzid: Africa/Malabo Eritrea (ER) tzid: Africa/Asmera Estonia (EE) tzid: Europe/Tallinn Ethiopia (ET) tzid: Africa/Addis_Ababa Falkland Islands (FK) tzid: Atlantic/Stanley Faroe Islands (FO) tzid: Atlantic/Faeroe Fiji (FJ) tzid: Pacific/Fiji Finland (FI) tzid: Europe/Helsinki France (FR) tzid: Europe/Paris French Guiana (GF) tzid: America/Cayenne French Polynesia (PF) tzid: Pacific/Gambier alias: SystemV/YST9 tzid: Pacific/Marquesas tzid: Pacific/Tahiti French Southern Territories (TF) tzid: Indian/Kerguelen Gabon (GA) tzid: Africa/Libreville Gambia (GM) tzid: Africa/Banjul Georgia (GE) tzid: Asia/Tbilisi Germany (DE) tzid: Europe/Berlin Ghana (GH) tzid: Africa/Accra Gibraltar (GI) tzid: Europe/Gibraltar Greece (GR) tzid: Europe/Athens Greenland (GL) tzid: America/Danmarkshavn tzid: America/Godthab tzid: America/Scoresbysund tzid: America/Thule Grenada (GD) tzid: America/Grenada Guadeloupe (GP) tzid: America/Guadeloupe Guam (GU) tzid: Pacific/Guam Guatemala (GT) tzid: America/Guatemala Guinea (GN) tzid: Africa/Conakry Guinea-Bissau (GW) tzid: Africa/Bissau Guyana (GY) tzid: America/Guyana Haiti (HT) tzid: America/Port-au-Prince Honduras (HN) tzid: America/Tegucigalpa Hong Kong S.A.R., China (HK) tzid: Asia/Hong_Kong alias: Hongkong Hungary (HU) tzid: Europe/Budapest Iceland (IS) tzid: Atlantic/Reykjavik alias: Iceland India (IN) tzid: Asia/Calcutta Indonesia (ID) tzid: Asia/Jakarta tzid: Asia/Jayapura tzid: Asia/Makassar alias: Asia/Ujung_Pandang tzid: Asia/Pontianak Iran (IR) tzid: Asia/Tehran alias: Iran Iraq (IQ) tzid: Asia/Baghdad Ireland (IE) tzid: Europe/Dublin alias: Eire Israel (IL) tzid: Asia/Jerusalem alias: Asia/Tel_Aviv alias: Israel Italy (IT) tzid: Europe/Rome Jamaica (JM) tzid: America/Jamaica alias: Jamaica Japan (JP) tzid: Asia/Tokyo alias: Japan Jordan (JO) tzid: Asia/Amman Kazakhstan (KZ) tzid: Asia/Almaty tzid: Asia/Aqtau tzid: Asia/Aqtobe tzid: Asia/Oral tzid: Asia/Qyzylorda Kenya (KE) tzid: Africa/Nairobi Kiribati (KI) tzid: Pacific/Enderbury tzid: Pacific/Kiritimati tzid: Pacific/Tarawa Kuwait (KW) tzid: Asia/Kuwait Kyrgyzstan (KG) tzid: Asia/Bishkek Laos (LA) tzid: Asia/Vientiane Latvia (LV) tzid: Europe/Riga Lebanon (LB) tzid: Asia/Beirut Lesotho (LS) tzid: Africa/Maseru Liberia (LR) tzid: Africa/Monrovia Libya (LY) tzid: Africa/Tripoli alias: Libya Liechtenstein (LI) tzid: Europe/Vaduz Lithuania (LT) tzid: Europe/Vilnius Luxembourg (LU) tzid: Europe/Luxembourg Macao S.A.R., China (MO) tzid: Asia/Macau alias: Asia/Macao Macedonia (MK) tzid: Europe/Skopje Madagascar (MG) tzid: Indian/Antananarivo Malawi (MW) tzid: Africa/Blantyre Malaysia (MY) tzid: Asia/Kuala_Lumpur tzid: Asia/Kuching Maldives (MV) tzid: Indian/Maldives Mali (ML) tzid: Africa/Bamako tzid: Africa/Timbuktu Malta (MT) tzid: Europe/Malta Marshall Islands (MH) tzid: Pacific/Kwajalein alias: Kwajalein tzid: Pacific/Majuro Martinique (MQ) tzid: America/Martinique Mauritania (MR) tzid: Africa/Nouakchott Mauritius (MU) tzid: Indian/Mauritius Mayotte (YT) tzid: Indian/Mayotte Mexico (MX) tzid: America/Cancun tzid: America/Chihuahua tzid: America/Hermosillo tzid: America/Mazatlan alias: Mexico/BajaSur tzid: America/Merida tzid: America/Mexico_City alias: Mexico/General tzid: America/Monterrey tzid: America/Tijuana alias: America/Ensenada alias: Mexico/BajaNorte Micronesia (FM) tzid: Pacific/Kosrae tzid: Pacific/Ponape tzid: Pacific/Truk tzid: Pacific/Yap Moldova (MD) tzid: Europe/Chisinau alias: Europe/Tiraspol Monaco (MC) tzid: Europe/Monaco Mongolia (MN) tzid: Asia/Choibalsan tzid: Asia/Hovd tzid: Asia/Ulaanbaatar alias: Asia/Ulan_Bator Montserrat (MS) tzid: America/Montserrat Morocco (MA) tzid: Africa/Casablanca Mozambique (MZ) tzid: Africa/Maputo Myanmar (MM) tzid: Asia/Rangoon Namibia (NA) tzid: Africa/Windhoek Nauru (NR) tzid: Pacific/Nauru Nepal (NP) tzid: Asia/Katmandu Netherlands (NL) tzid: Europe/Amsterdam Netherlands Antilles (AN) tzid: America/Curacao New Caledonia (NC) tzid: Pacific/Noumea New Zealand (NZ) tzid: Pacific/Auckland alias: NZ tzid: Pacific/Chatham alias: NZ-CHAT Nicaragua (NI) tzid: America/Managua Niger (NE) tzid: Africa/Niamey Nigeria (NG) tzid: Africa/Lagos Niue (NU) tzid: Pacific/Niue Norfolk Island (NF) tzid: Pacific/Norfolk North Korea (KP) tzid: Asia/Pyongyang Northern Mariana Islands (MP) tzid: Pacific/Saipan Norway (NO) tzid: Europe/Oslo Oman (OM) tzid: Asia/Muscat Pakistan (PK) tzid: Asia/Karachi Palau (PW) tzid: Pacific/Palau Palestinian Territory (PS) tzid: Asia/Gaza Panama (PA) tzid: America/Panama Papua New Guinea (PG) tzid: Pacific/Port_Moresby Paraguay (PY) tzid: America/Asuncion Peru (PE) tzid: America/Lima Philippines (PH) tzid: Asia/Manila Pitcairn (PN) tzid: Pacific/Pitcairn alias: SystemV/PST8 Poland (PL) tzid: Europe/Warsaw alias: Poland Portugal (PT) tzid: Atlantic/Azores tzid: Atlantic/Madeira tzid: Europe/Lisbon alias: Portugal Puerto Rico (PR) tzid: America/Puerto_Rico alias: SystemV/AST4 Qatar (QA) tzid: Asia/Qatar Réunion (RE) tzid: Indian/Reunion Romania (RO) tzid: Europe/Bucharest Russia (RU) tzid: Asia/Anadyr tzid: Asia/Irkutsk tzid: Asia/Kamchatka tzid: Asia/Krasnoyarsk tzid: Asia/Magadan tzid: Asia/Novosibirsk tzid: Asia/Omsk tzid: Asia/Sakhalin tzid: Asia/Vladivostok tzid: Asia/Yakutsk tzid: Asia/Yekaterinburg tzid: Europe/Kaliningrad tzid: Europe/Moscow alias: W-SU tzid: Europe/Samara Rwanda (RW) tzid: Africa/Kigali Saint Helena (SH) tzid: Atlantic/St_Helena Saint Kitts and Nevis (KN) tzid: America/St_Kitts Saint Lucia (LC) tzid: America/St_Lucia Saint Pierre and Miquelon (PM) tzid: America/Miquelon Saint Vincent and the Grenadines (VC) tzid: America/St_Vincent Samoa (WS) tzid: Pacific/Apia San Marino (SM) tzid: Europe/San_Marino Sao Tome and Principe (ST) tzid: Africa/Sao_Tome Saudi Arabia (SA) tzid: Asia/Riyadh Senegal (SN) tzid: Africa/Dakar Seychelles (SC) tzid: Indian/Mahe Sierra Leone (SL) tzid: Africa/Freetown Singapore (SG) tzid: Asia/Singapore alias: Singapore Slovakia (SK) tzid: Europe/Bratislava Slovenia (SI) tzid: Europe/Ljubljana Solomon Islands (SB) tzid: Pacific/Guadalcanal Somalia (SO) tzid: Africa/Mogadishu South Africa (ZA) tzid: Africa/Johannesburg South Georgia and the South Sandwich Islands (GS) tzid: Atlantic/South_Georgia South Korea (KR) tzid: Asia/Seoul alias: ROK Spain (ES) tzid: Africa/Ceuta tzid: Atlantic/Canary tzid: Europe/Madrid Sri Lanka (LK) tzid: Asia/Colombo Sudan (SD) tzid: Africa/Khartoum Suriname (SR) tzid: America/Paramaribo Svalbard and Jan Mayen (SJ) tzid: Arctic/Longyearbyen tzid: Atlantic/Jan_Mayen Swaziland (SZ) tzid: Africa/Mbabane Sweden (SE) tzid: Europe/Stockholm Switzerland (CH) tzid: Europe/Zurich Syria (SY) tzid: Asia/Damascus Taiwan (TW) tzid: Asia/Taipei alias: ROC Tajikistan (TJ) tzid: Asia/Dushanbe Tanzania (TZ) tzid: Africa/Dar_es_Salaam Thailand (TH) tzid: Asia/Bangkok Timor-Leste (TL) tzid: Asia/Dili Togo (TG) tzid: Africa/Lome Tokelau (TK) tzid: Pacific/Fakaofo Tonga (TO) tzid: Pacific/Tongatapu Trinidad and Tobago (TT) tzid: America/Port_of_Spain Tunisia (TN) tzid: Africa/Tunis Turkey (TR) tzid: Europe/Istanbul alias: Asia/Istanbul alias: Turkey Turkmenistan (TM) tzid: Asia/Ashgabat alias: Asia/Ashkhabad Turks and Caicos Islands (TC) tzid: America/Grand_Turk Tuvalu (TV) tzid: Pacific/Funafuti U.S. Virgin Islands (VI) tzid: America/St_Thomas alias: America/Virgin Uganda (UG) tzid: Africa/Kampala Ukraine (UA) tzid: Europe/Kiev tzid: Europe/Simferopol tzid: Europe/Uzhgorod tzid: Europe/Zaporozhye United Arab Emirates (AE) tzid: Asia/Dubai United Kingdom (GB) tzid: Europe/Belfast tzid: Europe/London alias: GB alias: GB-Eire United States (US) tzid: America/Adak alias: America/Atka alias: US/Aleutian tzid: America/Anchorage alias: SystemV/YST9YDT alias: US/Alaska tzid: America/Boise tzid: America/Chicago alias: CST6CDT alias: SystemV/CST6CDT alias: US/Central tzid: America/Denver alias: MST7MDT alias: Navajo alias: SystemV/MST7MDT alias: US/Mountain tzid: America/Detroit alias: US/Michigan tzid: America/Indiana/Knox alias: America/Knox_IN alias: US/Indiana-Starke tzid: America/Indiana/Marengo tzid: America/Indiana/Vevay tzid: America/Indianapolis alias: America/Fort_Wayne alias: America/Indiana/Indianapolis alias: EST alias: SystemV/EST5 alias: US/East-Indiana tzid: America/Juneau tzid: America/Kentucky/Monticello tzid: America/Los_Angeles alias: PST8PDT alias: SystemV/PST8PDT alias: US/Pacific alias: US/Pacific-New tzid: America/Louisville alias: America/Kentucky/Louisville tzid: America/Menominee tzid: America/New_York alias: EST5EDT alias: SystemV/EST5EDT alias: US/Eastern tzid: America/Nome tzid: America/North_Dakota/Center tzid: America/Phoenix alias: MST alias: SystemV/MST7 alias: US/Arizona tzid: America/Shiprock tzid: America/Yakutat tzid: Pacific/Honolulu alias: HST alias: SystemV/HST10 alias: US/Hawaii United States Minor Outlying Islands (UM) tzid: Pacific/Johnston tzid: Pacific/Midway tzid: Pacific/Wake Uruguay (UY) tzid: America/Montevideo Uzbekistan (UZ) tzid: Asia/Samarkand tzid: Asia/Tashkent Vanuatu (VU) tzid: Pacific/Efate Vatican (VA) tzid: Europe/Vatican Venezuela (VE) tzid: America/Caracas Vietnam (VN) tzid: Asia/Saigon Wallis and Futuna (WF) tzid: Pacific/Wallis Western Sahara (EH) tzid: Africa/El_Aaiun World (001) tzid: Etc/GMT alias: Etc/GMT-0 alias: Etc/GMT+0 alias: Etc/GMT0 alias: Etc/Greenwich alias: Etc/UCT alias: Etc/Universal alias: Etc/UTC alias: Etc/Zulu alias: GMT alias: GMT-0 alias: GMT+0 alias: GMT0 alias: Greenwich alias: UCT alias: Universal alias: UTC alias: Zulu tzid: Etc/GMT-1 tzid: Etc/GMT-2 tzid: Etc/GMT-3 tzid: Etc/GMT-4 tzid: Etc/GMT-5 tzid: Etc/GMT-6 tzid: Etc/GMT-7 tzid: Etc/GMT-8 tzid: Etc/GMT-9 tzid: Etc/GMT-10 tzid: Etc/GMT-11 tzid: Etc/GMT-12 tzid: Etc/GMT-13 tzid: Etc/GMT-14 tzid: Etc/GMT+1 tzid: Etc/GMT+2 tzid: Etc/GMT+3 tzid: Etc/GMT+4 tzid: Etc/GMT+5 tzid: Etc/GMT+6 tzid: Etc/GMT+7 tzid: Etc/GMT+8 tzid: Etc/GMT+9 tzid: Etc/GMT+10 tzid: Etc/GMT+11 tzid: Etc/GMT+12 Yemen (YE) tzid: Asia/Aden Zambia (ZM) tzid: Africa/Lusaka Zimbabwe (ZW) tzid: Africa/Harare Mark ----- Original Message ----- From: "Doug Royer" <Doug@Royer.com> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov>; "Tz (tz@elsie.nci.nih.gov)" <tz@lecserver.nci.nih.gov> Sent: Friday, February 04, 2005 10:30 Subject: Re: IANA time zone registration - proposal Thank you. This is not a proposal for an authority. This is a proposal for an iCalendar repository that uses the IETF iCalendar format used by an increasing number of calendaring applications. Synching the data can be as simple as a few line cron (batch) job that runs at some interval. A tool already exists that converts from the current TZ format and stores the data in iCalendar format. This just keeps the now few hundred of calendar applications from having to compile in static versions. Now if they get an appointment in the FOO/FEE time zone, they can query a source and find it in a way that is compatible to the IETF iCalendar format. Currently all vendors have had to make static snapshots, compile it into their code and hope. Mark Davis wrote:
I am quite leery about this project, having seen a number of other cases like this. The IANA charset registry, for example, is a real muddle; for example, some of the registered names are not compliant to the very specification they are supposed to be registered under, and there is nowhere near enough information in the registry to verify that the contents of a charset matches what is supposed to be registered.
I'm not sure that people here realize the implications of this proposal. It means either that all the timezone database identifier updates have to funnel through the IANA process, or that the data will get out of sync, and people won't know which is authoritative; the registry or the database.
While I do believe that it would be useful to have a more formal specification to answer certain issues that implementers need to depend on, at this point I would much rather see a single source. (And the proposed specification does not really add any information to what is already available.)
Mark
----- Original Message ----- From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> To: "Tz (tz@elsie.nci.nih.gov)" <tz@lecserver.nci.nih.gov> Cc: <doug@royer.com> Sent: Monday, January 17, 2005 12:22 Subject: FW: IANA time zone registration - proposal
Doug Royer is not on the time zone mailing list; direct replies appropriately.
--ado
-----Original Message----- From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM To: tz@lecserver.nci.nih.gov Subject: IANA time zone registration - proposal
[This was sent to some IETF mailing lists by me and someone suggested I
send
it to this list also]
This is REV -00 of the proposal - comments welcome. Data in in it can
easily
updated. (Like the TZ names updated to latest copy of data)
---------------------------------------------------- A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF.
A copy can be found at:
http://inet-consulting.com/draft-royer-timezone-registry-00.txt
And an HTML version:
http://inet-consulting.com/draft-royer-timezone-registry-00.html
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).
--
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
-- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards

Mark Davis wrote:
How are you approaching stability of tzids with iCalendar? Or is that not an issue in that domain?
It is not an issue. iCalendar is concerned with scheduling and coordinating between time zones. Our primary concern is getting the information in a RFC-2445 VTIMEZONE format. The computer program consuming these objects will not care if TZ-A or TZ-B are related. It will just need to do the TZ math and know that for the current user, on the 12th instance of the meeting it is at UTC-4 or whatever. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards
participants (7)
-
Clive D.W. Feather
-
Doug Royer
-
Ken Pizzini
-
Mark Davis
-
Markus Kuhn
-
Olson, Arthur David (NIH/NCI)
-
Paul Eggert