Time Zone Localizations

[Guy Harris]

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.