Time Zone Localizations

[Mark Davis]

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 at alum.mit.edu>
To: "Mark Davis" <mark.davis at jtcsv.com>
Cc: <tz at 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.
>
>