I'm afraid I left the wrong impression, by being too brief. I agree with your statements: one can do two possible things: // maintaining stability YU => Europe/Belgrade CS => Europe/Prague or // not maintaining stability YU => Europe/Belgrade CS => Europe/Belgrade Note that the draft successor to RFC3066 uses the UN geographic codes whenever ISO duplicates a code, since unlike the ISO codes, the UN codes are stable. So it maps 891 => Europe/Belgrade // 891 is Serbia and Montenegro Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Guy Harris" <guy@alum.mit.edu> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Thu, 2004 Jun 10 19:06 Subject: Re: Time Zone Localizations
On Jun 10, 2004, at 6:40 PM, Mark Davis wrote:
As to Yugoslavia, that is a real mess, because the ISO committee just doesn't care about stability of identifiers. You can have a database set up with someone's country of birth stored as CS. All of a sudden by some whim of ISO, that data is invalidated. More on that at http://www.unicode.org/consortium/utc-positions.html#2stability.
Yes, but the Europe/Belgrade zone isn't missing a country (the country happens to have changed, and its name and 3166 country code changed as a result, but it's currently a zone for Serbia and Montenegro), and Yugoslavia either
1) isn't a country any more, and thus can't have a zone
or
2) is now called "Serbia and Montenegro" and thus has the Europe/Belgrade zone.
I.e., it's not that Europe/Belgrade is missing a country, it's that it's missing a country with a stable ISO 3166 country code, and it's not that Yugoslavia is missing a zone, it's that it's not called "Yugoslavia" any more.
The only way I'd see that as being an issue would be if, in the proposed lookup mechanism, a "country" is identified by its Alpha-2 ISO 3166-1 code; that's the best-known code, and looks as if it might be the only one for which you don't have to pay the ISO a significant amount of money for, but if Alpha-3 or the numeric code doesn't have the stability problems that Alpha-2 has, perhaps, if a unique identifier for countries is needed, you could use that. (Or use some special internal codes for Serbia and Montenegro and Czechoslovakia that aren't two-letter codes.)
I.e., it's a mess, but it's not sufficient of a mess to make it impossible to talk about times and time zones in Serbia and Montenegro in CLDR, or to speak of the locale for the region corresponding to Europe/Belgrade, or to use "ZZ" as the country code for "Europe/Belgrade".
Asia/Riyadh{87,88,89}: Saudi Arabia, SA - those are historical, from an era when Saudi Arabia used solar time, and apply only to Riyadh (and, if you're really fussy, to a particular location in Riyadh, I guess), so they're not appropriate for Saudi Arabia as a whole. I don't know what names you'd give them. ... WET, CET, MET, and EET "are for backward compatibility with older versions"; various Europe/XXX rules should presumably be used instead - I guess you could pick cities for each of them.
For these, I guess my recommendation would be to not bother translating them at all -- they are all compatibility orphans, one wouldn't encourage their use.
Asia/Riyadh{87,88,89} aren't compatibility orphans; the corresponding country is Saudi Arabia, we just don't happen to have time zone information for the entire country prior to their adopting a standard time zone - and, according to mail from Paul Eggert:
http://www.imc.org/ietf-calendar/archive1/msg02618.html
"Nobody uses solar time any more for civil time. The last holdout was Saudi Arabia; they converted to UTC+3 in 1950."
so I'm not sure why we even still have the "solar{87,88,89}" files any more, as that seems to imply that they *didn't* use solar time in 1987, 1988, or 1989.