I have a couple of questions that I hope someone can give guidance on. These are sparked by the change from IDs like "America/Catamarca" to "America/Argentina/Catamarca" In CLDR (http://unicode.org/cldr/), we are using the IDs to access different localized names for the time zones. Each time a zone ID changes, we have the choice of either updating all the localized files that use that ID, or leaving them be and using the old ID. To make our maintenance easier (and make it easier for implementations), I'm inclined to recommend that we maintain stability as of a given date; that we never change an ID after that point. 1. Would there be any downside to such a policy? 2. I was not able to find documentation as to whether there is a policy disallowing 'retired' IDs to be reused later for a different timezone. Some might think that it is so obviously a bad policy to reuse IDs that it doesn't need stating, but ISO has reused country codes, for example, causing no end of problems for stability. 3. What was the reason for the change for Argentina? Is this a one-off aberration, or can we expect America/Chicago to change to America/United States/Chicago, America/Vancouver to change to America/Canada/Vancouver, and so on down the line? 4. Are links expected to be definitional and stable? That is, if I ever have two IDs that are related by a link: Link A B Can it ever be the case in the future that the IDs A and B are "unlinked", and given different rules? Or is it that links in certain files are stable? 5. A side note: when examining the links, and assuming that they are of the form Link <new> <old> there are a small number of links that are "not final", meaning that what they link to, itself links to something else. While not formally an issue, it might be more convenient (and transparent) if these were put in a 'canonical' form. 13 America/Rosario => America/Cordoba # NOT FINAL => America/Argentina/Cordoba 39 Brazil/Acre => America/Porto_Acre # NOT FINAL => America/Rio_Branco 79 GMT+0 => Etc/GMT+0 # NOT FINAL => Etc/GMT 80 GMT-0 => Etc/GMT-0 # NOT FINAL => Etc/GMT 81 GMT0 => Etc/GMT0 # NOT FINAL => Etc/GMT 82 Greenwich => Etc/Greenwich # NOT FINAL => Etc/GMT 99 Navajo => America/Shiprock # NOT FINAL => America/Denver 137 Universal => Etc/Universal # NOT FINAL => Etc/UTC 139 Zulu => Etc/Zulu # NOT FINAL => Etc/UTC Mark
"Mark Davis" <mark.davis@jtcsv.com> writes:
I'm inclined to recommend that we maintain stability as of a given date; that we never change an ID after that point.
1. Would there be any downside to such a policy?
Only if somebody builds the database without the "backwards" file, which lists the backwards-compatibility names. The default is to include "backwards", as it includes very common IDs like US/Pacific. I'd be surprised (but not astonished) if someone omitted it.
2. I was not able to find documentation as to whether there is a policy disallowing 'retired' IDs to be reused later for a different timezone.
It's never happened in the past, and I'd be surprised if it needed to happen in the future. Backwards compatibility is a big deal.
3. What was the reason for the change for Argentina?
San Juan needed a (new) entry, and "America/San_Juan" would have been too ambiguous: there are several other important San Juans in America.
Is this a one-off aberration, or can we expect America/Chicago to change to America/United States/Chicago, America/Vancouver to change to America/Canada/Vancouver, and so on down the line?
I wouldn't rule it out, but I think it unlikely in our lifetimes. If it happens, we'll put in backwards-compatibility links.
4. Are links expected to be definitional and stable? That is, if I ever have two IDs that are related by a link:
Link A B
Can it ever be the case in the future that the IDs A and B are "unlinked", and given different rules?
Yes. For example, currently Asia/Jerusalem and Asia/Tel_Aviv are links, but it's conceivable that political changes might cause them to use different rules. (Israeli politics are pretty strange sometimes.)
there are a small number of links that are "not final", meaning that what they link to, itself links to something else. While not formally an issue, it might be more convenient (and transparent) if these were put in a 'canonical' form.
Thanks for catching those; I'll do that in my next proposed patch.
<<On Mon, 03 Jan 2005 14:24:48 -0800, Paul Eggert <eggert@CS.UCLA.EDU> said:
Only if somebody builds the database without the "backwards" file, which lists the backwards-compatibility names. The default is to include "backwards", as it includes very common IDs like US/Pacific. I'd be surprised (but not astonished) if someone omitted it.
FreeBSD does not use "backwards": ---------------------------- revision 1.6 date: 1994/09/13 21:54:06; author: wollman; state: Exp; lines: +36 -133 New method for installing timezone data files, not nearly as complicated as the previous one, and better integrated with the build scheme. Define OLDTIMEZONES to get backward-compatibility links added. Define LEAPSECONDS if you want leap-second support. ============================================================================= This change was made prior to the release of FreeBSD 2.0. FreeBSD 1.x (long obsolete) did support the old names. (I don't recall whether it supported the new names, but I suspect it didn't.) -GAWollman
On Monday, January 3 2005, "Paul Eggert" wrote to "Mark Davis, Tz (tz@elsie.nci.nih.gov)" saying:
"Mark Davis" <mark.davis@jtcsv.com> writes:
I'm inclined to recommend that we maintain stability as of a given date; that we never change an ID after that point.
1. Would there be any downside to such a policy?
Only if somebody builds the database without the "backwards" file, which lists the backwards-compatibility names. The default is to include "backwards", as it includes very common IDs like US/Pacific. I'd be surprised (but not astonished) if someone omitted it.
I wonder if it would be a good idea to separate the old-style names (US/Eastern, etc.) from compatibility versions of old Area/Location names. It seems like FreeBSD and similar systems would in general want to have the latter even if not the former. -- Jonathan Lennox lennox at cs dot columbia dot edu
Jonathan Lennox <lennox@cnr.cs.columbia.edu> writes:
I wonder if it would be a good idea to separate the old-style names (US/Eastern, etc.) from compatibility versions of old Area/Location names. It seems like FreeBSD and similar systems would in general want to have the latter even if not the former.
It's not entirely clear which is which for Australian names like "Australia/Canberra". However, here's a little awk script that you can apply to the "backwards" file if you want just the old Area/Location names. BEGIN { area["Africa"] = 1; area["America"] = 1; area["Antarctica"] = 1 area["Arctic"] = 1; area["Asia"] = 1; area["Atlantic"] = 1 area["Etc"] = 1; area["Europe"] = 1 area["Indian"] = 1; area["Pacific"] = 1 # Australia is special; it's old-style names (I think). } /^Link/ && area[substr($3, 1, index($3, "/") - 1)]
participants (4)
-
Garrett Wollman -
Jonathan Lennox -
Mark Davis -
Paul Eggert