Time Zone Localizations
Chuck Soper
chucks at lmi.net
Fri Jun 11 07:21:04 UTC 2004
I think that the tables listed at this link could
be revised to improve clarity:
http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/zone_log.html
Are these tables informational or vital to the
process? For example, will the Aliases table be
used to "Canonicalize the Olson ID" (step 1 of
the Fallback procedure)? If so, then the table
should be based on the current time zone data
files instead of "current Java data". This could
turn into a serious maintenance issue. Ideally, I
think that a script could be run on the time zone
data files to generate a new aliases table each
time the time zone data files are updated
(currently tzdata2004a).
### Aliases
The Aliases table appears to contain time zone
names from several different tzdata2004a files:
backward, etcetera, and systemv. If you use
several different tables such as backward
aliases, etcetera aliases, and systemv aliases
then I expect that they would be easier to
maintain as the time zone database is updated.
I suggest avoiding terms like 'Bogus' and 'Real'
because they're not very descriptive. Here are
some possible new terms:
'Bogus' to 'Obsolete Olson ID from tzdata2004a/backward'
'Real' to 'Valid Olson ID as of tzdata2004a'
The 'Bogus' column in the Aliases table contains
both obsolete and valid time zone names.
Antarctica/South_Pole and America/Shiprock are
valid; they are both listed in the
tzdata2004a/zone.tab file. These files correspond
to (are equal to) Antarctica/McMurdo and
America/Denver respectively but that doesn't
necessarily mean that they are invalid or bogus.
Where did AET (line 2, Aliases table) for
Australia/Sydney come from? I can't find any
reference to it in tzdata2004a.
### Country to Zones
The 'Country to Zones' looks good, yet it
contains at least one obsolete country code, YU
for Yugoslavia. I realize that this is a known
issue. You can use the tzdata2004a/zone.tab file
to generate an updated 'Country to Zones' table.
For obsolete ISO 3166 country codes such as YU I
think that ISO 3166-3 could be referenced. ISO
3166-3 represents codes for formerly used names
of countries:
http://www.niso.org/standards/resources/3166.html
http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/iso3166-3.html
Each ISO 3166-3 entry has several fields
including a four letter code where the first two
letters are the formerly used code and the last
two letters are the code that replaced it. The
four letter code for Yugoslavia is 'YUCS'.
The ISO web site says that ISO 3166-3 was first
published in 1998 (or maybe 1999), but I cannot
find the original document. Yes, it would be
ironic if the standard for formerly used names is
formerly used.
Should CLDR (or the time zone database) maintain
a list of formerly used country codes? This would
be similar to the backward file to maintain
obsolete time zone names.
### Countries that are missing Zones
Could this table be renamed to 'Country Codes that do not have Zones'?
Of course, Yugoslavia shouldn't be in the table.
### Zones that are missing Countries
Could this table be renamed to "Zones that do not map to specific Countries"?
Europe/Belgrade is in this list, yet it's listed
in the tzdata2004a/zone.tab file with a country
code of CS. I suppose this is a know issue
related to the YU country code for Yugoslavia.
I don't think that Asia/Riyadh87, Asia/Riyadh88,
and Asia/Riyadh89 belong in this list. They
correspond to the tzdata2004a files: solar87,
solar88, and solar89. Should they go in the alias
table(s)?
### Windows IDs
This table seems to imply that there is a
one-to-one relationship between Olson IDs and
Windows IDs. Since you only have 75 Windows IDs
listed, I suspect that one Windows ID may map to
one or more Olson IDs.
### Equivalent Modern Zones
My first reaction whenever I see a significant
effort to simplify something for the user is to
think that it could lead to problems. How did you
determine that "A lot of people just don't care
about historic differences"? Do most people use
time zones merely to keep track of the current
time or current differences between another time
zone? How else do users use time zones?
That's all for now. I hope that my comments are useful.
Chuck
At 6:40 PM -0700 6/10/04, Mark Davis wrote:
>Thanks for your feedback.
>
>> Bouvet Island - an uninhabited volcanic island, almost entirely
>...
>> Etc/GMT{[+-]N} are just for fixed GMT offsets; they don't correspond to
> > countries.
>
>Yes, we realize that Bouvet Island and Heard Island and McDonald Islands are
>completely obscure places; it is more for a
>matter of API/testing completeness.
>Understood that Etc/GMT... don't correspond to
>countries. But in an API and for
>translation, it is useful to have everything attached to a country, even if it
>is a pseudo-country. That's why the suggestion
>in the document is to use ZZ for
>them, which is a private-use ISO country code, which can be translated as "no
>country".
>
>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.
>
>> 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.
>
>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 18:11
>Subject: Re: Time Zone Localizations
>
>
>>
>> On Jun 10, 2004, at 12:04 PM, Mark Davis wrote:
>>
>> > I'd very much appreciate any feedback on the proposal.
>>
>> Some of the countries listed as missing zones are:
>>
>> Bouvet Island - an uninhabited volcanic island, almost entirely
>> covered by glaciers, controlled by Norway, and designated as a nature
>> reserve, according to
>>
>> http://www.cia.gov/cia/publications/factbook/geos/bv.html
>>
>> I don't know if the automated meteorological station on the island
>> cares about time zones or not.
>>
>> Heard Island and McDonald Islands - uninhabited, barren, sub-Antarctic
>> islands now controlled by Australia, designated as a nature preserve,
>> according to
>>
>> http://www.cia.gov/cia/publications/factbook/geos/hm.html
>>
>> They don't even mention any automated meteorological stations, just
>> seals and birds.
>>
>> Yugoslavia - it's now Serbia and Montenegro. Europe/Belgrade is the
>> correct zone for it.
>>
>> Some of the time zones listed as missing countries are:
>>
>> Europe/Belgrade: Serbia and Montenegro, which has the ISO 3166-1
>> Alpha-2 code CS, according to
>>
>> http://www.iso.org/iso/en/prods-services/iso3166ma/01whats-new/2003
>> -07-23_statement_cs.html
>>
>> 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.
>>
>> Etc/GMT{[+-]N} are just for fixed GMT offsets; they don't correspond to
>> countries.
>>
>> 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.
>>
>>
More information about the tz
mailing list