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.

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.

Hmmm. If the UN codes are not stable either, then we have even more issues to deal with. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Clive D.W. Feather" <clive@demon.net> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Guy Harris" <guy@alum.mit.edu>; <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 07:36 Subject: Re: Time Zone Localizations

Mark Davis said:

...

Note that the draft successor to RFC3066

Can you give me a pointer to that?

...

uses the UN geographic codes whenever ISO duplicates a code, since unlike the ISO codes, the UN codes are stable.

Except when they aren't. Like Ethiopia or Panama.

-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

Clive D.W. Feather scripsit:

...

uses the UN geographic codes whenever ISO duplicates a code, since unlike the ISO codes, the UN codes are stable.

Except when they aren't. Like Ethiopia or Panama.

They are not stable in the sense of never changing. They are stable in the sense of never being reassigned, unlike both the 2-alphas and the 3-alphas. -- Some people open all the Windows; John Cowan wise wives welcome the spring jcowan@reutershealth.com by moving the Unix. http://www.reutershealth.com --ad for Unix Book Units (U.K.) http://www.ccil.org/~cowan (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif)

ISO rules in ISO 3601-1 allow for the re-assignment of 2-alpha codes, ten years after a previously assigned code was withdrawn. regards - Jake -----Original Message----- From: Clive D.W. Feather [mailto:clive@demon.net] Sent: June 15, 2004 7:36 AM To: jcowan@reutershealth.com Cc: tz@lecserver.nci.nih.gov Subject: Re: Time Zone Localizations jcowan@reutershealth.com said:

...

...

uses the UN geographic codes whenever ISO duplicates a code, since unlike the ISO codes, the UN codes are stable.

They are not stable in the sense of never changing. They are stable in the sense of never being reassigned, unlike both the 2-alphas and the 3-alphas.

You hope. What guarantee do you have? -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

Mark Davis said:

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".

I wouldn't use ZZ, because it's useful for AA and ZZ to lie outside the range of codes used. Rather, use one of the other private-use codes - isn't OO available? If I've misremembered that, then certainly QQ and QZ are. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

Infoman said:

IN ISO 3166-1, in the 3-digit numeric codes, the 900+-999 range is available for private use. Some of these are already "taken", i.e. in widespread use. I note that banking and financial services (ISO TC68) standardards for financial transactions do use the 3-digit numeric code because it is the most stable.

The numeric codes serve a different purpose to the alphabetic ones - they identify physical territory. So when a country changes name and therefore alpha code, the number stays the same. But when the territory changes (e.g. absorption of East by West Germany) the number changes even if the alpha code stays the same. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

Infoman said:

Actually the numbers stay the same, Russia retains the number for the Soviet Union and united Germany retained the number for West-Germany. [...] The same happened re Ethiopia (& Eritrea), Yugoslavia, etc.

Not so. On 1990-10-30: DD DDR 278 withdrawn (3166-3 entry DDDE) DE DEU 280 replaced DE DEU 276 added New numeric code for the same political entity (Federal Germany). On 1992-06-15: SU SUN 810 withdrawn (3166-3 entry SUHH) RU RUS 643 added (and others, e.g. KZ KAZ 398) New numeric code because Russia was not the USSR. On 1990-08-14: YD YMD 720 withdrawn (3166-3 entry YDYE) YE YEM 886 replaced YE YEM 887 added Merged Yemen got a new number. On 1993-07-22: PA PAN 590 replaced PA PAN 591 added Panama got a new number when it absorbed the Canal Zone (which didn't have one). On 1993-07-16: ET ETH 230 replaced ET ETH 231 added ER ERI 232 added Ethiopia got a new number when Eritrea split off. On 1993-07-28: YU YUG 890 replaced YU YUG 891 added Yugoslavia got a new number to recognise that it was really just Serbia and Montenegro (and this number transferred to the new CS SCG code).

The perspective here is that of a jurisdictional nature. Even though the physical territory may change, the jurisdictional entity remains.

And the numeric code changes - see above.

The 3 digit numeric code and the 3-alpha code belong to are under the control of the UN and maintained by the UN Statistical system. The the official long and short names of each country are under the control of each country. However changes in names or names for "new" countries are vetted by the UN. Normally proposed changes do go through "automatically". Only rarely does a UN member object (e.g. as is the current case with "Macedonia).

The ISO 3166-1 standard takes this UN originated information and then adds/manages the 2-alpha codes.

If you look at the ISO3166MA web site, you'll see that only the numeric codes come from the UN Statistics Division. I can't find my copy of 3166, but I believe you'll find this distinction between alpha and numeric codes in it. I believe you'll also find there is a 4-digit code as well, which is derived from the two letter code by the calculation 1070+30a+b, where a represents the first letter and b the second letter (A=1, B=2, etc.). In this code, AF is 1106 and GB is 1282. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

Infoman said:

Thanks very much. My apologies and I stand to be corrected.

You're welcome. Can you prod the people who wrote that PDF you circulated earlier? They'll take more notice of you than me.

The information that I sent was based on that provided by the UN people in their Statistical Division. It is now obvious that whomever, I spoke to and corresponded with three years ago, is not as precise as the "lord of time".

<grin> -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

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

comments interleaved below. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Chuck Soper" <chucks@lmi.net> To: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 00:21 Subject: Re: Time Zone Localizations

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/zon...

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).

The tables are informational, just to provide a different view of the data and provide background for the issues involved. The end goal is to work off of the current time zone data, as provided on ftp://elsie.nci.nih.gov/pub/. It may be necessary to supplement that data, e.g. to have a list of 'outmoded codes' like WET, CET, MET, EET, Asia/Riyadh87, Asia/Riyadh88, Asia/Riyadh89; or add IDs for missing country codes, but we would really far rather that all the data could come from ftp://elsie.nci.nih.gov/pub/.

### 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.

Good. Part of our supplementary data could be which whole tables to exclude.

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.

You're right: Bogus is an overly familiar term. However, to reduce the translation requirements and make the data more manageable, we do want to set up some uniqueness criteria. If two IDs have exactly the same behavior since the time when time zones were adopted, and have always been in the same country over that period, we only want one of them to be in the main list. The other can be an alternate -- and still work-- but we would recommend an extremely low priority on translation.

Where did AET (line 2, Aliases table) for Australia/Sydney come from? I can't find any reference to it in tzdata2004a.

There are some aliases that come from Java. That is noted in the document, but probably not clearly enough.

### 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/...

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.

There is separate discussion on the email list on the instability of ISO codes. Unfortunately, the ISO committee makes no stability guarantees about 3 letter codes either.

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.

We would probably use the same mechanism as the RFC 3066bis; that once a country code is introduced by ISO, we never retract it. If they introduce a different meaning for that code, we don't follow them -- and instead use the UN code.

### 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.

Yes, and you are correct on Yugoslavia. (Apparently the Java implementation filters that out).

### Zones that are missing Countries Could this table be renamed to "Zones that do not map to specific Countries"?

Yes

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.

Yes

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)?

They really sound like items we should just ignore, for the purposes of these document, since they are not really useful.

### 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.

There should be more explanation. These are, to the best of our knowledge, the appropriate mappings to use for Windows IDs, but its presence here is only informational. Windows doesn't try to do historic time zones, nor do they cover all of the modern timezones completely.

### 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?

Many (I would dare say the vast majority) of end users just don't care now that there was once a difference between Dawson, Whitehorse and Los Angeles. When they pick a timezone in some preferences dialog (on their machine, in a website preferences page, etc) they just want to see one choice for that zone, not three different ones that they have to think about. The UI might have an advanced button (as the text discusses) for someone who does really care, but that will be a very small proportion of users.

That's all for now. I hope that my comments are useful. Chuck

Absolutely! Actually, another question. We have traditionally referred to the timezone IDs in ftp://elsie.nci.nih.gov/pub/ as "Olson IDs". What is the best way to refer to them?

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 ? '¤÷ËÕZY¤½Ë¼·¬Ë»¦Z?ÕÃË ?

----- 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 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.

There are 29 countries that have multiple zones. If you show only modern zones, you have 99 different zones for those countries; if you show historic zones, you have 164, a considerable increase. For example, for the US you have the following, with a ';' between zones that are the same nowadays, and ';' between ones that are different. It clutters up the UI and adds more translation requirements if you need to distinguish non-modern zones. Pacific/Honolulu; America/Adak; America/Anchorage, America/Nome, America/Juneau, America/Yakutat; America/Los_Angeles; America/Phoenix; America/Denver, America/Boise; America/Chicago, America/North_Dakota/Center, America/Menominee; America/Indianapolis, America/Indiana/Knox, America/Indiana/Vevay, America/Indiana/Marengo; America/New_York, America/Kentucky/Monticello, America/Detroit, America/Louisville Note: we're not saying the modern equivalents must be identified; this is more a matter of setting priorities for translation. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 12:41 Subject: Re: Time Zone Localizations

<<On Fri, 11 Jun 2004 11:49:03 -0700, "Mark Davis" <mark.davis@jtcsv.com> said:

[Text formatting recovered.]

...

Many (I would dare say the vast majority) of end users just don't care now that there was once a difference between Dawson, Whitehorse and Los Angeles. When they pick a timezone in some preferences dialog (on their machine, in a website preferences page, etc) they just want to see one choice for that zone, not three

There are really very few cases where you might give people multiple choices, having already selected a particular country or national region. In the tzsetup(8) user interface which I wrote, users must first select a region and then a "country" (scare quotes because they are actually selecting a 3166-2 code behind the scenes, but the interface doesn't tell them that). The US probably provides most of the complicated cases once you've gotten that far; few other countries have more than one historic zone for each existing modern zone. In any event, if the user has already selected a locale, then you should default to presenting only the time zones associated with the country or region identified by the locale, with an option to "see all". There is no need to identify "equivalent" time zones when most of them are already known to be largely irrelevant.

There is a separate localization issue that comes up when trying to answer the question, "What time is it in _____?". I don't know if the scope of your project extends to that question.

-GAWollman

Those pesky non-English speakers! But there is a point: simply because I don't speak Russian does mean that I would have no occasion to see or use time zones that happen to be in Russia. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>; <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 15:49 Subject: Re: Time Zone Localizations

<<On Fri, 11 Jun 2004 15:01:15 -0700, "Mark Davis" <mark.davis@jtcsv.com> said:

...

ones that are different. It clutters up the UI and adds more translation requirements if you need to distinguish non-modern zones.

...

Pacific/Honolulu; America/Adak; America/Anchorage, America/Nome, America/Juneau, America/Yakutat; America/Los_Angeles; America/Phoenix; America/Denver, America/Boise; America/Chicago, America/North_Dakota/Center, America/Menominee; America/Indianapolis, America/Indiana/Knox, America/Indiana/Vevay, America/Indiana/Marengo; America/New_York, America/Kentucky/Monticello, America/Detroit, America/Louisville

Well, except that you don't need to translate any of these, unless you're really interested in supporting `ko_US' or the like. None of these are relevant to any other country. Their existence should not cause a maintenance burden for other locales. Likewise, there is no need to perform a Swahili translation for the multitude of Brazilian locales.

-GAWollman

<<On Fri, 11 Jun 2004 16:30:53 -0700, "Mark Davis" <mark.davis@jtcsv.com> said:

Those pesky non-English speakers! But there is a point: simply because I don't speak Russian does mean that I would have no occasion to see or use time zones that happen to be in Russia.

It is, however, less likely that you would need to do so. You *were* writing about the need to prioritize translation efforts; it seems clear to me that the translation of all zones into their "native" locale should be given a higher priority than translating any zone into a language in which it is rarely referenced. Some zones may never need to be translated. Procedurally, I would suggest: foreach zone { foreach locale used in country of zone { translate all symbols used in this zone translate identifier of zone if necessary } } ; break point 1 foreach locale { foreach equivalence class of proleptically isomorphic zones { choose exemplar appropriate for this locale translate all symbols used in exemplar translate identifier of exemplar if necessary } } ; break point 2 translate remaining symbols and identifiers -GAWollman

Mark Davis scripsit:

However, to reduce the translation requirements and make the data more manageable, we do want to set up some uniqueness criteria. If two IDs have exactly the same behavior since the time when time zones were adopted,

In fact the Olson data do not separate timezones in a given country that have been the same since 1970-01-01. Otherwise, Indiana would have something like 30 time zones instead of just four.

and have always been in the same country over that period, we only want one of them to be in the main list. The other can be an alternate -- and still work-- but we would recommend an extremely low priority on translation.

I think that is a mistake, for two reasons: national chauvinism and future-proofing. About the former, nothing need be said; but the whole point of setting your zone to the country you are in (especially if you live there) is that you don't want to have to reset it if your national legislature changes the rules, either the DST rules or the zone proper. Within the EU, DST rules are harmonized, but which zone to adopt is a purely national decision.

Many (I would dare say the vast majority) of end users just don't care now that there was once a difference between Dawson, Whitehorse and Los Angeles.

This strikes me as backwards. If you're in the U.S., you should see U.S. choices; in Canada you should see Canadian ones.

Absolutely!

I think the series of fallbacks is unnecessarily complex. In particular, the fallback from "Pacific Time" to "GMT-07:00/08:00" doesn't tell me that much, because I don't know a priori whether it's winter or summer currently. In addition, it fails to exploit the nice thing about the use of city names in Olson, namely that city names don't need that much localization: in the vast majority of cases, the internationally known name is the only name. (Transliteration might be required if the current locale has no Latin letters.) Thus the full combinatorial explosion of city name x language can mostly be short-circuited. I propose a simpler scheme, therefore: 1) If you have a translation for the time zone name x the language, use it. 2a) Get the localized name for the city (or if none, the Olson city name); 2b) Get the "Tampo de '%1'" schema for the language (or if none, use just "%1"); 2c) Substitute the city name into the schema and use that. When I'm communicating with users about the Reuters Health system, I always refer to events occurring at such-and-such a time, New York time. That communicates not only a GMT offset but a set of DST rules. This is also what's typically done in legal documents -- see the legal ads for bond redemption announcements in a newspaper. -- John Cowan <jcowan@reutershealth.com> http://www.reutershealth.com I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, LOTR:FOTR

Mark Davis scripsit:

America/Dawson, America/Whitehorse, America/Vancouver;

Yes, I agree that this kind of variation can be merged away for localization purposes. I didn't understand it before.

Look at London, from the CLDR:

Yes, well, Europe is a particularly bad case, because they all have local names for each others' locations. I rather doubt that the same applies to Vancouver or Winnipeg or Iqaluit. As I said before, you may want to apply your transliteration engine when you know there's a script barrier.

There are 239 countries. Of them, 210 have a single zone. Using a country name for each of them is essentially free.

Yes, that is the Right Thing.

But we still need some fallback in case there is no unique country, and no translated city.

Use the Olson name of the city in that case. It's not ideal, but it still helps a great deal. (Transliterated when necessary.)

Of course, the chances of something sensible like this are, well, zip.]

Not really. The appropriate time for DST changes depends on latitude, and in the Southern Hemisphere it goes the other way. -- As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone jcowan@reutershealth.com will die someday. http://www.reutershealth.com --From a Nigerian-type scam spam http://www.ccil.org/~cowan

"Mark Davis" <mark.davis@jtcsv.com> writes:

We have traditionally referred to the timezone IDs in ftp://elsie.nci.nih.gov/pub/ as "Olson IDs". What is the best way to refer to them?

The zdump(8) man page says "zonenames". Perhaps "Olson zone names"?

"Mark Davis" <mark.davis@jtcsv.com> writes:

it sounds like Olson zone identifier or maybe Olson time zone identifier?

RFC 2445 calls these sorts of things TZIDs, so perhaps "Olson TZID"? Or if you want to spell out "identifier", then "Olson TZ identifier"? They are used as values of the TZ environment variable, so "TZ" has a good pedigree.

"Mark Davis" <mark.davis@jtcsv.com> writes:

ftp://elsie.nci.nih.gov/pub/

Is there a stable link to a document that we could cite as the specification for the IDs, instead of just pointing to an FTP site?

When you ask for a "specification for the IDs", do you mean "which TZIDs are in the Olson database?" or "what syntax is allowed for the TZIDs?"? Either way, I'd say that the FTP site is the stable reference. According to my records that location dates back to April 25, 1992, so it's one of the most stable links on the planet.

"Mark Davis" <mark.davis@jtcsv.com> writes:

like "olson_tzid_specification.txt" (or .html or .pdf) that people can read to tell them how the Olson TZIDs are defined by the data files in that directory.

If you just want a list of TZIDs, then the zone.tab file is perhaps your best bet right now. Admittedly there's no single URL for it but it's not hard to give directions for deriving it. If you want to know exactly the data are derived then the zic man page is the specification. You can Google "zic man page" if it's too much of a pain to unpack it from the canonical location.

"Mark Davis" <mark.davis@jtcsv.com> writes:

we can't point people to a document that they can read, that describes a specification.

I don't see why not. If you want a list of Olson TZIDs, you can make a copy of zone.tab, and point people at it. Or if you want the specification for the zic input file format, you can make a copy of the zic man page, and point people at that. This stuff is all in the public domain. On the other hand, if the existing documentation is not enough for your needs, then it might be helpful if you could write something that will do the job, and contribute it back to the mainline distribution. Documentation is often the hardest job in volunteer efforts like these, and I'd welcome any good contributions in this area.

There are general rules for choosing TZID names and various other things in the "Theory" file within tzdata. I'm not sure if that helps Mark, because I'm not really clear on exactly what sort of specifications he is looking for. But in any case, newcomers seem to have difficulty finding things like the naming conventions in the Theory file. It might be worth putting pointers to the Theory file from tzcode and the zone.tab file from tzdata in places like http://www.twinsun.com/tz/tz-link.htm and maybe the README for tzcode. Perhaps there should even be a short README for tzdata and/or ftp://elsie.nci.nih.gov/pub/. ] The latter is what we need; it needed be a long document, and I'd be glad to put ] together a draft for your consideration. ] ] Mark ] __________________________________ ] http://www.macchiato.com ] ___ _______________________________________________________________ ___ ] ] ----- Original Message ----- ] From: "Paul Eggert" <eggert@CS.UCLA.EDU> ] To: "Mark Davis" <mark.davis@jtcsv.com> ] Cc: <tz@lecserver.nci.nih.gov> ] Sent: Fri, 2004 Jun 11 23:33 ] Subject: Re: Time Zone Localizations ] ] ] > "Mark Davis" <mark.davis@jtcsv.com> writes: ] > ] > > we can't point people to a document that they can read, that ] > > describes a specification. ] > ] > I don't see why not. If you want a list of Olson TZIDs, you can make ] > a copy of zone.tab, and point people at it. Or if you want the ] > specification for the zic input file format, you can make a copy of ] > the zic man page, and point people at that. This stuff is all in the ] > public domain. ] > ] > On the other hand, if the existing documentation is not enough for ] > your needs, then it might be helpful if you could write something that ] > will do the job, and contribute it back to the mainline distribution. ] > Documentation is often the hardest job in volunteer efforts like ] > these, and I'd welcome any good contributions in this area. ___________________________________________________________________________ David Keegel <djk@cybersource.com.au> http://www.cyber.com.au/users/djk/ Cybersource P/L: Linux/Unix Systems Administration Consulting/Contracting

Mark Davis scripsit:

3. What is the meaning of an TZID

Just what is the meaning of "meaning" in this context?

4. What is the versioning scheme, including assurance that: - once a version is issued it is never changed. - TZIDs are stable, in the sense that they will never be withdrawn or reused with a substantially different semantic in later versions

Again, what does that mean? New York might move to a new timezone, if Congress so decided, or if it became an independent country (hey, we pay them more than they pay us). In that case the Eastern zone would have to be renamed America/Philadelphia, or whatever. More probably, Congress might change the DST rules, in which case the current predictions of the U.S. zones would become incorrect and would have to be updated. The only other conceivable scenario would be for the Big Apple to have its name changed (Nueva York might be a possibility). In that case, some other New York might come to prominence such that it became the largest city in some other time zone in the Americas. That's not very likely, but it would constitute a genuine reuse. The advantage and disadvantage of Olson TZIDs is that they aren't arbitrary: they depend entirely on facts on the ground. -- John Cowan jcowan@reutershealth.com http://www.reutershealth.com "Mr. Lane, if you ever wish anything that I can do, all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything, you can put the telegram down as a forgery."

"Mark Davis" <mark.davis@jtcsv.com> writes:

There are at least two choices:

1. America/New_York will always be the timezone for the city of New York, even if it secedes from the US, joins Canada, and goes on Newfoundland time.

That's correct.

2. America/New_York is a stand-in for US Eastern Time. If New York City secedes and changes, the America/New_York TZID will associated with US Eastern Time.

No, America/New_York is intended to be New York time.

And if America/New_York is to be stable, that would, of course, be a huge mistake,

That's what the 'backward' file is for. For example, when we discovered that the name "Ulaanbaatar" had become far more common in English than "Ulan Bator", we renamed Asia/Ulan_Bator to Asia/Ulaanbaatar and put a link in the "backward" file. This sort of thing happens occasionally, just as ISO 3166 renames country codes.

they have to have a clear meaning so that when the "facts on ground" change, one can have reasonable expectations as to what principles would be maintained in adjusting the TZIDs to the new circumstances.

This issue is discussed at length in the Theory file.

"Mark Davis" <mark.davis@jtcsv.com> writes:

1. What are the all valid Olson TZIDs 2. How to determine which are 'canonical' and which are simply included for compatibility ... 5. An explicit description of the data representation for all of the data files.

We've covered these issues in our emails so far, I think, so all you'd need to do is write it all down.

3. What is the meaning of an TZID

Sorry, I don't know what you mean by "meaning of a TZID". A TZID is just a name. But perhaps you can just consult the Theory file to see the naming convention.

4. What is the versioning scheme,

You can get many (most?) old versions at <ftp://munnari.oz.au/pub/oldtz/>; the versioning scheme should be fairly evident though I suppose it wouldn't hurt to write it up.

including assurance that:

I'm afraid there is no warranty of any kind. This is entirely an informal volunteer effort.

- once a version is issued it is never changed.

That's been true in practice. For example, once tzdata2003d.tar.gz was issued, it wasn't changed; instead a newer version tzdata2003e.tar.gz was issued.

- TZIDs are stable, in the sense that they will never be withdrawn or reused with a substantially different semantic in later versions

That's also been true in practice, mostly. Generally speaking, TZIDs are never withdrawn; they're just moved to the 'backward' file. However, I can think of one exception. In 1994 some of the GMT-related TZIDs did change their semantics to conform to POSIX. For example, the old TZID "GMT-12" was withdrawn and its replacement is called "Etc/GMT+12"; this because POSIX required a different semantics for TZ="GMT-12". This sort of confusion is one of the reasons why I don't encourage the use of TZIDs like "Etc/GMT+12".

Yes, it would be very nice if there were explicit data in the database that would allow someone to programmatically derive the following: 1. The set of links to not skip (because then there would be country IDs with no TZID).

Arctic/Longyearbyen // or Atlantic/Jan_Mayen, don't care which Europe/Bratislava Europe/Ljubljana Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Vatican Europe/Zagreb (http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/zon... og.html#skipped_aliases)

2. The set of oddballs to skip (in forming a choice list) WET, CET, MET, EET, Asia/Riyadh87, Asia/Riyadh88, Asia/Riyadh89 3. And if the database had unique TZIDs corresponding to the 'missing' ISO country codes BV, HM, and a mapping in zone.tab for those, and from some private-use ISO country code to the GMT* codes (I suggested ZZ, but any one of the following are available: AA, QM-QZ, XA-XZ and ZZ). Actually, if the oddballs in #2 just didn't have a mapping from a private-use ISO code, that would suffice. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov>; "Chuck Soper" <chucks@lmi.net> Sent: Fri, 2004 Jun 11 17:08 Subject: Re: Time Zone Localizations

"Mark Davis" <mark.davis@jtcsv.com> writes:

...

If two IDs have exactly the same behavior since the time when time zones were adopted, and have always been in the same country over that period, we only want one of them to be in the main list.

If two Olson zone names are aliased via a "Link" command in the Olson database, it could be that they are true aliases (e.g., Asia/Nicosia and Europe/Nicosia) or it could be that they happen to be same since 1970 and differed before then but we're not sure about the details (e.g., Europe/Oslo and Arctic/Longyearbyen) or it could be that they happen to have been the same since time zones were introduced but quite possibly will differ in the future (e.g., Antarctica/McMurdo and Antarctica/South_Pole). The database itself doesn't tell you which of these possibilities apply (though the comments give hints). However, one can safely conclude that if the Link command is in the "backward" or "etcetera" file then it is a true alias.

I think that for your purposes it's probably safe to ignore all Link commands, except perhaps for those needed to establish the existence of an Olson zone name for a particular country. If by "country" one means ISO 3166 country code, these zone names would be:

Arctic/Longyearbyen Europe/Bratislava Europe/Ljubljana Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Vatican Europe/Zagreb

Mark Davis wrote:

Actually, this is directly related, since LDML is the format used for CLDR. However, the comment is based on a misunderstanding: LDML currently does allow for translation of *all* of the timezone IDs, modern and historical.

I guess you don't translate timezone IDs... Anyway, do you mean that LDML allows users to define DTD? (Sorry if this is not a correct way to talk about XML...) So the syntax of <zone> is really user-defined? Thanks, Masayoshi

The problems we are trying to address with this proposal are that the sheer volume of translations is difficult to manage, *and* many languages just don't have corresponding terms. And we didn't give guidance before as to which IDs were the most important to translate, so the translations that are in CLDR were not done in any kind of priority order.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 06:43 Subject: Re: Time Zone Localizations

This is a bit off from the proposal, but related to time zone localizations.

It appears that the Locale Data Markup Language spec for <timeZoneNames> (http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that a time zone has a single set of long and short names, which assumption is not valid if a system supports historical time zone changes. Actually, the time zone support in Java has this problem because it supports historical changes since 1.4 and always display the "latest" time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I couldn't due to another commitment.

Is it possible for CLDR to make corrections to the <timeZoneNames> spec so that it can represent all historical name changes?

Thanks, -- Masayoshi Okutsu Java Internationalization Sun Microsystems (K.K.)

Mark Davis wrote:

...

The common locale data repository project (CLDR) hosted by the Unicode consortium (www.unicode.org/cldr/) provides for translations of time zone IDs, based on the public domain time zone database at ftp://elsie.nci.nih.gov/pub/.

A

...

number of issues have come up concerning those translations, and we have put together a proposal for changing the way that is done. The goal would be to

make

...

changes in CLDR 1.1, which would be released around mid-October of this year. The current version of the proposal is at:

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim...

one_localization.html

...

I'd very much appreciate any feedback on the proposal.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

Probably you have misunderstood my first question... Many zones have changed their time zones in their history. It's not a valid assumption that a single zone ID represents a single time zone. It may be confusing to say "zone changes time zones". Let me give you an example. Here's the history of Asia/Singapore. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT During 1942-02-16 until 1945-09-12, Asia/Singapore's time zone was Japan Standard Time (GMT+09:00). (Sorry if this isn't a good example...) The LDML spec didn't look like supporting all historical time zones within a single zone. So what I'd like to see is something organized like: <zone type="Asia/Singapore" > <zoneNameSet format="SGT"> <long> <generic>Singapore Time</generic> <standard>Singapore Time</standard> <daylight>Singapore Time</daylight> </long> <short> <generic>SGT</generic> <standard>SGT</standard> <daylight>SGT</daylight> </short> </zoneNameSet> ... <zoneNameSet format="LMT"> <long> <generic>Local Mean Time</generic> ... <short> <generic>LMT</generic> ... </zoneNameSet> <exemplarCity>Singapore</exemplarCity> </zone> Obviously use of this structure involves redundant names. Probably it should have all name sets which can be referred to by <zone>. I got several bug reports on Java time zone support because it supports all historical changes since 1.4. Some customers were just confused with historically correct local time. Some of them could have been avoided if Java was capable of giving historically correct time zone names. Hope my question is now clearer. Thanks, Masayoshi Mark Davis wrote:

I don't know where you are getting that. They are *not* user-defined IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs as matching the IDs in ftp://elsie.nci.nih.gov/pub/. See also http://www.unicode.org/cldr/data_formats.html#Display_Names also.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 08:41 Subject: Re: Time Zone Localizations

Mark Davis wrote:

...

Actually, this is directly related, since LDML is the format used for CLDR. However, the comment is based on a misunderstanding: LDML currently does allow for translation of *all* of the timezone IDs, modern and historical.

I guess you don't translate timezone IDs... Anyway, do you mean that LDML allows users to define DTD? (Sorry if this is not a correct way to talk about XML...) So the syntax of <zone> is really user-defined?

Thanks, Masayoshi

...

The problems we are trying to address with this proposal are that the sheer volume of translations is difficult to manage, *and* many languages just don't have corresponding terms. And we didn't give guidance before as to which IDs were the most important to translate, so the translations that are in CLDR were not done in any kind of priority order.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 06:43 Subject: Re: Time Zone Localizations

This is a bit off from the proposal, but related to time zone localizations.

It appears that the Locale Data Markup Language spec for <timeZoneNames> (http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that a time zone has a single set of long and short names, which assumption is not valid if a system supports historical time zone changes. Actually, the time zone support in Java has this problem because it supports historical changes since 1.4 and always display the "latest" time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I couldn't due to another commitment.

Is it possible for CLDR to make corrections to the <timeZoneNames> spec so that it can represent all historical name changes?

Thanks, -- Masayoshi Okutsu Java Internationalization Sun Microsystems (K.K.)

Mark Davis wrote:

...

The common locale data repository project (CLDR) hosted by the Unicode consortium (www.unicode.org/cldr/) provides for translations of time zone IDs, based on the public domain time zone database at ftp://elsie.nci.nih.gov/pub/.

A

...

number of issues have come up concerning those translations, and we have put together a proposal for changing the way that is done. The goal would be to

make

...

changes in CLDR 1.1, which would be released around mid-October of this year. The current version of the proposal is at:

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim...

z

...

...

one_localization.html

...

I'd very much appreciate any feedback on the proposal.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

I think we may be talking past one another. LDML provide for a way to *localize* the Olson TZIDs. For example, you can localize the term "Asia/Singapore". That latter ID is the thing that identifies a timezone. It does not at all attempt to provide an alternative to *computing* the results of applying the Olson TZID to any given point in time. That is left to the implementation of the Olson time zone database. There is no need, nor desire, to duplicate that in the LDML. As far as we are concerned, 'historic' time zone support simply means the ability for the time zone computation to reflect differences in behavior that existed in the past but no longer exist. An implementation that was only limited to 'modern' time zones (like Windows, or older Java or ICU) would not be able to distinguish between two zones that have the same behavior now, but differed at some time in the past. So the Olson time zone database encompasses historic time zones, and has historic time zone IDs that LDML allows people to attach localizations to. Is that clearer? Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sat, 2004 Jun 12 07:35 Subject: Re: Time Zone Localizations It's strange. I responded to your message about 13 hours ago, but it doesn't show up yet... Let me try again (with a short version). I believe you misunderstood my first question. It's simply an invalid assumption that a zone (in the Olson zoneinfo) represents a single time zone. How do you describe the following with the LDML spec, for example? # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT If the given date is, for example, 1942-02-16, the local time zone name has to be "JST" (in the short form). I didn't think LDML would allow for defining historical time zone names. I didn't mean "historical" tome zone *IDs*. (I really don't understand "modern" and "historical" in your message, though. All of (most of?) the zones are modern. They just have their own history. And we just don't know what will happen to zones in the future. What you think is "modern" today might be "historical" tomorrow.) Thanks, Masayoshi Mark Davis wrote:

I don't know where you are getting that. They are *not* user-defined IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs as matching the IDs in ftp://elsie.nci.nih.gov/pub/. See also http://www.unicode.org/cldr/data_formats.html#Display_Names also.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 08:41 Subject: Re: Time Zone Localizations

Mark Davis wrote:

...

Actually, this is directly related, since LDML is the format used for CLDR. However, the comment is based on a misunderstanding: LDML currently does allow for translation of *all* of the timezone IDs, modern and historical.

I guess you don't translate timezone IDs... Anyway, do you mean that LDML allows users to define DTD? (Sorry if this is not a correct way to talk about XML...) So the syntax of <zone> is really user-defined?

Thanks, Masayoshi

...

The problems we are trying to address with this proposal are that the sheer volume of translations is difficult to manage, *and* many languages just don't have corresponding terms. And we didn't give guidance before as to which IDs were the most important to translate, so the translations that are in CLDR were not done in any kind of priority order.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 06:43 Subject: Re: Time Zone Localizations

This is a bit off from the proposal, but related to time zone localizations.

It appears that the Locale Data Markup Language spec for <timeZoneNames> (http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that a time zone has a single set of long and short names, which assumption is not valid if a system supports historical time zone changes. Actually, the time zone support in Java has this problem because it supports historical changes since 1.4 and always display the "latest" time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I couldn't due to another commitment.

Is it possible for CLDR to make corrections to the <timeZoneNames> spec so that it can represent all historical name changes?

Thanks, -- Masayoshi Okutsu Java Internationalization Sun Microsystems (K.K.)

Mark Davis wrote:

...

The common locale data repository project (CLDR) hosted by the Unicode consortium (www.unicode.org/cldr/) provides for translations of time zone IDs, based on the public domain time zone database at ftp://elsie.nci.nih.gov/pub/.

A

...

number of issues have come up concerning those translations, and we have put together a proposal for changing the way that is done. The goal would be to

make

...

changes in CLDR 1.1, which would be released around mid-October of this year. The current version of the proposal is at:

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim... _

z

...

...

one_localization.html

...

I'd very much appreciate any feedback on the proposal.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

I am just not quite understanding what you are getting at. In CLDR, the English translation of the TZID Asia/Singapore would be in the en locale data; the Japanese translation of TZID Asia/Singapore would be in the ja locale file, etc. (Note: we don't necessarily have the data for everything yet, but the LDML format allows all of that.) The best I can make out, it sounds like what you want would be the 1942 Japanese names for the TZID Asia/Singapore, etc.. While it would certainly be possible to do that with CLDR by providing a variant locale (ja-JP-1942), it seems rather odd. When I generate a date right now, and the date happens to be in the past at some time, I don't generate it with the conventions that would have applied in *on that date* (unless I am doing a historical novel, for example). I don't write 1624-1-15 as "The Fifteenth Day of January in the Year of Our Lord Nineteen-Hundred Four-and-Twenty", or whatever would have been accepted usage at the time: I write it (in en_US) as "January 15th, 1624" (or some other modern equivalent). So I must still be misunderstanding you. (Also, we looked at using the Olson TZID abbreviations, but they don't appear to have wide currency -- people in the countries in question didn't seem to be familiar with them -- so we decided not to use them.) Mark (BTW, I will be on a trip next week, and won't be able to reply very often on this subject) __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sun, 2004 Jun 13 05:36 Subject: Re: Time Zone Localizations Probably *my* comment wasn't clear enough for you. But I believe that I've been talking about the same thing as what was pointed out by Paul (the second bullet of Message-id: <87isdxxm5a.fsf@penguin.cs.ucla.edu>). I *am* talking about the names part, not the computing part. For example, Java is capable of *computing* correct local time as of 1942-02-16 in Asia/Singapore. However, since Java has only the last time zone (display) names (i.e., "Singapore Time" and "SGT" for Asia/Singapore), Java date/time formatting produces "Singapore Time" or "SGT" for 1942-02-16, which should be "Japan Standard Time" or "JST". (tzcode is capable of producing correct abbreviations. But I didn't think that abbreviation only support for historic names was appropriate for Java and I didn't add them in 1.4.) I see the same issue in the LDML spec in <timeZoneNames> as Java currently has. My earlier comment included the following which may explain what I'd like to see in the LDML spec. <timeZoneNames> <zone type="America/Los_Angeles" > <zoneNameSet format="SGT"> <long> <generic>Singapore Time</generic> ... </long> <short> <generic>SGT</generic> ... </short> </zoneNameSet> ... <zoneNameSet format="LMT"> <long> <generic>Local Mean Time</generic> ... </long> <short> <generic>LMT</generic> ... </short> </zoneNameSet> </zone> ... </timeZoneNames> The format="..." may be problematic. But I haven't thought out any real syntax for the requirement. Thanks, Masayoshi Mark Davis wrote:

I think we may be talking past one another. LDML provide for a way to *localize* the Olson TZIDs. For example, you can localize the term "Asia/Singapore". That latter ID is the thing that identifies a timezone.

It does not at all attempt to provide an alternative to *computing* the results of applying the Olson TZID to any given point in time. That is left to the implementation of the Olson time zone database. There is no need, nor desire, to duplicate that in the LDML.

As far as we are concerned, 'historic' time zone support simply means the ability for the time zone computation to reflect differences in behavior that existed in the past but no longer exist. An implementation that was only limited to 'modern' time zones (like Windows, or older Java or ICU) would not be able to distinguish between two zones that have the same behavior now, but differed at some time in the past. So the Olson time zone database encompasses historic time zones, and has historic time zone IDs that LDML allows people to attach localizations to.

Is that clearer?

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sat, 2004 Jun 12 07:35 Subject: Re: Time Zone Localizations

It's strange. I responded to your message about 13 hours ago, but it doesn't show up yet... Let me try again (with a short version).

I believe you misunderstood my first question. It's simply an invalid assumption that a zone (in the Olson zoneinfo) represents a single time zone. How do you describe the following with the LDML spec, for example?

# Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT

If the given date is, for example, 1942-02-16, the local time zone name has to be "JST" (in the short form). I didn't think LDML would allow for defining historical time zone names. I didn't mean "historical" tome zone *IDs*. (I really don't understand "modern" and "historical" in your message, though. All of (most of?) the zones are modern. They just have their own history. And we just don't know what will happen to zones in the future. What you think is "modern" today might be "historical" tomorrow.)

Thanks, Masayoshi

Mark Davis wrote:

...

I don't know where you are getting that. They are *not* user-defined IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs as matching the

IDs

...

in ftp://elsie.nci.nih.gov/pub/. See also http://www.unicode.org/cldr/data_formats.html#Display_Names also.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 08:41 Subject: Re: Time Zone Localizations

Mark Davis wrote:

...

Actually, this is directly related, since LDML is the format used for CLDR. However, the comment is based on a misunderstanding: LDML currently does allow for translation of *all* of the timezone IDs, modern and historical.

I guess you don't translate timezone IDs... Anyway, do you mean that LDML allows users to define DTD? (Sorry if this is not a correct way to talk about XML...) So the syntax of <zone> is really user-defined?

Thanks, Masayoshi

...

The problems we are trying to address with this proposal are that the sheer volume of translations is difficult to manage, *and* many languages just don't have corresponding terms. And we didn't give guidance before as to which IDs were the most important to translate, so the translations that are in CLDR

were

...

...

not done in any kind of priority order.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 06:43 Subject: Re: Time Zone Localizations

This is a bit off from the proposal, but related to time zone localizations.

It appears that the Locale Data Markup Language spec for <timeZoneNames> (http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that a time zone has a single set of long and short names, which assumption is not valid if a system supports historical time zone changes. Actually, the time zone support in Java has this problem because it supports historical changes since 1.4 and always display the "latest" time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I couldn't due to another commitment.

Is it possible for CLDR to make corrections to the <timeZoneNames> spec so that it can represent all historical name changes?

Thanks, -- Masayoshi Okutsu Java Internationalization Sun Microsystems (K.K.)

Mark Davis wrote:

...

The common locale data repository project (CLDR) hosted by the Unicode consortium (www.unicode.org/cldr/) provides for translations of time zone

IDs,

...

...

...

based on the public domain time zone database at

ftp://elsie.nci.nih.gov/pub/.

...

...

...

A

...

number of issues have come up concerning those translations, and we have put together a proposal for changing the way that is done. The goal would be to

make

...

changes in CLDR 1.1, which would be released around mid-October of this year. The current version of the proposal is at:

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim e

_

...

...

...

z

...

...

one_localization.html

...

I'd very much appreciate any feedback on the proposal.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

Well, that turns out not to be the case.

You are saying that if I generated a series of dates, one per year, going back 100 years, that the format would change in the middle? If my spreadsheet did that, I'd figure it was a bug -- *not* a feature. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "John Cowan" <cowan@ccil.org> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sun, 2004 Jun 13 20:05 Subject: Re: Time Zone Localizations

Mark Davis scripsit:

...

When I generate a date right now, and the date happens to be in the past at some time, I don't generate it with the conventions that would have applied in *on that date* (unless I am doing a historical novel, for example).

Well, that turns out not to be the case. Try "date -d 1943-01-01" on a system where GNU 'date' is available (Linux, e.g.) Set TZ to an American time zone first if need be.

...

(Also, we looked at using the Olson TZID abbreviations, but they don't appear to have wide currency -- people in the countries in question didn't seem to be familiar with them -- so we decided not to use them.)

They are not meant to be authentic, and exist because time libraries are expected to provide a time zone abbreviation even where they don't really exist.

-- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable

Mark Davis scripsit:

You are saying that if I generated a series of dates, one per year, going back 100 years, that the format would change in the middle? If my spreadsheet did that, I'd figure it was a bug -- *not* a feature.

Time zones are infested with the Real World, I fear. L.A. was on UTC-7 in January 1943, but it would be incorrect to call that Pacific Daylight Time. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com All "isms" should be "wasms". --Abbie

Probably I've given you a confusing example. It's not related to Japanese locale at all. Since Paul and others have given another examples, like "Pacific War Time". I don't think I'd need to give additional examples. It is confusing to produce *correct* (past) local time with the current time zone name as if the current GMT offset and DST rules were applied to the local time. Thanks, Masayoshi Mark Davis wrote:

I am just not quite understanding what you are getting at. In CLDR, the English translation of the TZID Asia/Singapore would be in the en locale data; the Japanese translation of TZID Asia/Singapore would be in the ja locale file, etc. (Note: we don't necessarily have the data for everything yet, but the LDML format allows all of that.)

The best I can make out, it sounds like what you want would be the 1942 Japanese names for the TZID Asia/Singapore, etc.. While it would certainly be possible to do that with CLDR by providing a variant locale (ja-JP-1942), it seems rather odd. When I generate a date right now, and the date happens to be in the past at some time, I don't generate it with the conventions that would have applied in *on that date* (unless I am doing a historical novel, for example). I don't write 1624-1-15 as "The Fifteenth Day of January in the Year of Our Lord Nineteen-Hundred Four-and-Twenty", or whatever would have been accepted usage at the time: I write it (in en_US) as "January 15th, 1624" (or some other modern equivalent).

So I must still be misunderstanding you.

(Also, we looked at using the Olson TZID abbreviations, but they don't appear to have wide currency -- people in the countries in question didn't seem to be familiar with them -- so we decided not to use them.)

Mark

(BTW, I will be on a trip next week, and won't be able to reply very often on this subject)

__________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sun, 2004 Jun 13 05:36 Subject: Re: Time Zone Localizations

Probably *my* comment wasn't clear enough for you. But I believe that I've been talking about the same thing as what was pointed out by Paul (the second bullet of Message-id: <87isdxxm5a.fsf@penguin.cs.ucla.edu>). I *am* talking about the names part, not the computing part.

For example, Java is capable of *computing* correct local time as of 1942-02-16 in Asia/Singapore. However, since Java has only the last time zone (display) names (i.e., "Singapore Time" and "SGT" for Asia/Singapore), Java date/time formatting produces "Singapore Time" or "SGT" for 1942-02-16, which should be "Japan Standard Time" or "JST". (tzcode is capable of producing correct abbreviations. But I didn't think that abbreviation only support for historic names was appropriate for Java and I didn't add them in 1.4.) I see the same issue in the LDML spec in <timeZoneNames> as Java currently has.

My earlier comment included the following which may explain what I'd like to see in the LDML spec.

<timeZoneNames> <zone type="America/Los_Angeles" > <zoneNameSet format="SGT"> <long> <generic>Singapore Time</generic> ... </long> <short> <generic>SGT</generic> ... </short> </zoneNameSet> ... <zoneNameSet format="LMT"> <long> <generic>Local Mean Time</generic> ... </long> <short> <generic>LMT</generic> ... </short> </zoneNameSet> </zone> ... </timeZoneNames>

The format="..." may be problematic. But I haven't thought out any real syntax for the requirement.

Thanks, Masayoshi

Mark Davis wrote:

...

I think we may be talking past one another. LDML provide for a way to

*localize*

...

the Olson TZIDs. For example, you can localize the term "Asia/Singapore". That latter ID is the thing that identifies a timezone.

It does not at all attempt to provide an alternative to *computing* the results of applying the Olson TZID to any given point in time. That is left to the implementation of the Olson time zone database. There is no need, nor desire,

to

...

duplicate that in the LDML.

As far as we are concerned, 'historic' time zone support simply means the ability for the time zone computation to reflect differences in behavior that existed in the past but no longer exist. An implementation that was only

limited

...

to 'modern' time zones (like Windows, or older Java or ICU) would not be able

to

...

distinguish between two zones that have the same behavior now, but differed at some time in the past. So the Olson time zone database encompasses historic

time

...

zones, and has historic time zone IDs that LDML allows people to attach localizations to.

Is that clearer?

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sat, 2004 Jun 12 07:35 Subject: Re: Time Zone Localizations

It's strange. I responded to your message about 13 hours ago, but it doesn't show up yet... Let me try again (with a short version).

I believe you misunderstood my first question. It's simply an invalid assumption that a zone (in the Olson zoneinfo) represents a single time zone. How do you describe the following with the LDML spec, for example?

# Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT

If the given date is, for example, 1942-02-16, the local time zone name has to be "JST" (in the short form). I didn't think LDML would allow for defining historical time zone names. I didn't mean "historical" tome zone *IDs*. (I really don't understand "modern" and "historical" in your message, though. All of (most of?) the zones are modern. They just have their own history. And we just don't know what will happen to zones in the future. What you think is "modern" today might be "historical" tomorrow.)

Thanks, Masayoshi

Mark Davis wrote:

...

I don't know where you are getting that. They are *not* user-defined IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs as matching the

IDs

...

in ftp://elsie.nci.nih.gov/pub/. See also http://www.unicode.org/cldr/data_formats.html#Display_Names also.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 08:41 Subject: Re: Time Zone Localizations

Mark Davis wrote:

...

Actually, this is directly related, since LDML is the format used for CLDR. However, the comment is based on a misunderstanding: LDML currently does

allow

...

...

...

for translation of *all* of the timezone IDs, modern and historical.

I guess you don't translate timezone IDs... Anyway, do you mean that LDML allows users to define DTD? (Sorry if this is not a correct way to talk about XML...) So the syntax of <zone> is really user-defined?

Thanks, Masayoshi

...

The problems we are trying to address with this proposal are that the sheer volume of translations is difficult to manage, *and* many languages just

don't

...

...

...

have corresponding terms. And we didn't give guidance before as to which IDs were the most important to translate, so the translations that are in CLDR

were

...

...

not done in any kind of priority order.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- From: "Masayoshi Okutsu" <Masayoshi.Okutsu@Sun.COM> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Fri, 2004 Jun 11 06:43 Subject: Re: Time Zone Localizations

This is a bit off from the proposal, but related to time zone localizations.

It appears that the Locale Data Markup Language spec for <timeZoneNames> (http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that a time zone has a single set of long and short names, which assumption is not valid if a system supports historical time zone changes. Actually, the time zone support in Java has this problem because it supports historical changes since 1.4 and always display the "latest" time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I couldn't due to another commitment.

Is it possible for CLDR to make corrections to the <timeZoneNames> spec so that it can represent all historical name changes?

Thanks, -- Masayoshi Okutsu Java Internationalization Sun Microsystems (K.K.)

Mark Davis wrote:

...

The common locale data repository project (CLDR) hosted by the Unicode consortium (www.unicode.org/cldr/) provides for translations of time zone

IDs,

...

...

...

based on the public domain time zone database at

ftp://elsie.nci.nih.gov/pub/.

...

...

...

A

...

number of issues have come up concerning those translations, and we have put together a proposal for changing the way that is done. The goal would be to

make

...

changes in CLDR 1.1, which would be released around mid-October of this

year.

...

...

...

...

The current version of the proposal is at:

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim

e

...

...

...

...

_

...

...

...

z

...

...

one_localization.html

...

I'd very much appreciate any feedback on the proposal.

Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

I must not be making the situation clear. The internal code is invariant across locales. But the "display name" for that code will change dramatically. That is, the TZID will not change. But its representation to local users must; because they may not know English. For example, "Europe/London" will remain constant. But the "display name" for it will reflect the representations of London (or "British Time"), such as the following: "Londain": ·ga· "Londen": ·nl· "London": ·da· ·en· ·fr· ·sv· "Londra": ·it· "Londres": ·es· ·pt· "Lontoo": ·fi· "ロンドン": ·ja· "伦敦": ·zh· "倫敦": ·zh_Hant· "런던": ·ko· Expecting otherwise is like expecting you to recognize 倫敦 as the name of a TZID. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Guy Harris" <guy@alum.mit.edu> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Masayoshi Okutsu" <Masayoshi.Okutsu@sun.com>; <tz@lecserver.nci.nih.gov> Sent: Sun, 2004 Jun 13 20:14 Subject: Re: Time Zone Localizations

On Sat, Jun 12, 2004 at 09:24:34AM -0700, Mark Davis wrote:

...

I think we may be talking past one another. LDML provide for a way to *localize* the Olson TZIDs. For example, you can localize the term "Asia/Singapore".

Actually, "Asia/Singapore" is, in the Olson code, a relative pathname, so, in all locales, it's "Asia/Singapore" - i.e., the localization function is a no-op.

You might want to localize a textual description of that region, but that's a different matter.

Thanks very much for your comments. I put up a new version of http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim... which tries to address these comments and some of the others that I've gotten on this list. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sat, 2004 Jun 12 00:37 Subject: Re: Time Zone Localizations

"Mark Davis" <mark.davis@jtcsv.com> writes:

...

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim...

Commenting on the version of 2004-06-11:

* The document uses the term "CLDR" without defining it.

* 'These translations mark a difference between "generic" usage (aka "wall time") like "Pacific Time" and a fixed offset from GMT like "Pacific Standard Time" or "Pacific Daylight Time", and also allow for both abbreviated and full names.'

This doesn't seem to allow for variants in names (e.g. DST in Los Angeles has variously been called "Pacific Daylight Time", "Pacific War Time", and "Pacific Peace Time"). Nor does it seem to allow for double DST.

* The document defines "modern" equivalents as those that produce the same result for the current year. More accurate, I think, would be that two zones would have to predict the same results for the current year, the next year, the year after that, etc. In some cases two zones might predict the same results for the current year, but not for next year.

* "windows ids shows a mapping from windows IDs to Olson IDs." You might mention that this is a one-to-many mapping, and the Olson ID is chosen somewhat arbitrarily.

* "reset of the year" -> "rest of the year"

* 'If there is an exact translation, use it. America/Los_Angeles => "Pacific Time"'

This example doesn't seem to allow for the case where a city changes time zones. These things happen. (It just happened in Argentina last week.)

If you really want a name that means US Pacific Time, you'll need to supply one. Historically the Olson TZID "US/Pacific" served this purpose, but it has been supplanted by geographical IDs partly to avoid ambiguity, partly to avoid controversy.

* 'America/Los_Angeles => "Tampo de San Fransisko"' I don't understand this example. Why is Los Angeles being translated as if it were San Fransisco?

* "Note that the results are semi-reversible; one cannot necessarily recover the exact time zone that one started with, but can recover a modern equivalent." I don't understand this claim completely, but I'm skeptical. Natural-language time notations are notoriously ambiguous.

* "In Mexico one would prefer to see the America/Mexico_City timezone (appropriately localized), while in the US, the America/Chicago one." This is not merely an issue of ease-of-use: it is also important when one wants to specify the desired behavior in the presence of likely future changes. In 2001, the mayor of Mexico City threatened to abolish DST in that city, and the matter remains somewhat controversial, so it's quite possible that the Mexico City and Chicago will diverge in the not-too-distant future.

* Some of the document uses notations like "GMT+7" to mean west of Greenwich; some of it uses the same notation to mean east of Greenwich. It should be consistent. I suggest "GMT+7" to mean east of Greenwich. Also, these days it's more technically accurate to write "UTC" instead of "GMT".

* At the HTML level the document specifies charset=windows-1252 and the four HTML lines containing non-ASCII characters didn't come out right in my browser. Can you please use plain ASCII instead, e.g., use "«" instead of the Windows-1252 byte that means left-pointing double angle quotation mark? Or it may be simpler to reformulate the examples to avoid non-ASCII characters.

* I don't really understand the proposal. Sorry. It's fairly complicated and I don't fully understand the intended use or the motivation. Could be this is because I'm not in the CLDR universe. Anyway, this means I can't really comment on the fundamentals of the document, only on relatively-minor issues like the above.

Thanks again. Some comments below. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄ ----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sat, 2004 Jun 12 19:31 Subject: Re: Time Zone Localizations

"Mark Davis" <mark.davis@jtcsv.com> writes:

...

http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim...

A few comments on the 2004-06-12 edition:

* Re "Eastern European Daylight Time". A more common English translation is "Eastern European Summer Time". This is certainly true for British English, and tends to be true even for American sources like the Olson database.

A bit of background. CLDR permits different translations for different locales, so the same TZID could be translated as "Eastern European Daylight Time" for en_US (the US English locale), and "Eastern European Summer Time" for en_UK. It all depends on what would be better understood in each place. Of course, if there is a single term that would work for all English locales, it is better to use that. I filed http://www.jtcsv.com/cgibin/locale-bugs?findid=152 on this.

I think the usual idioms in practice are as follows.

legend: - generic time name (and abbreviation) 0 standard time name (and abbreviation) 1 daylight-saving time name (and abbreviation)

example of typical American English style: - Eastern Time (ET) 0 Eastern Standard Time (EST) 1 Eastern Daylight Time (EDT)

example of typical Australian English style: - Eastern Time (ET) 0 Eastern Standard Time (EST) 1 Eastern Summer Time (EST)

example of typical European English style: - Eastern European Time (EET) 0 Eastern European Time (EET) 1 Eastern European Summer Time (EEST)

Note that some names and/or abbreviations are ambiguous in some locales. This suggests that one may run into some problems with the idea of having UIs use names to distinguish the cases labeled "-", "0", "1".

For any given locale, we would disallow a collision between names. Thus for the locale en (English) we can't have AST mean both Alaska Standard Time and Atlantic Standard Time. What we can do is have AST mean one in en_US and another in en_CA (Canada).

This is somewhat related to the issue I previously mentioned that, even in the same locale, the name differs depending on what time stamps you're talking about. For example "Pacific War Time" should be used for daylight-saving time in Los Angeles from 1942-02-09 through 1945-08-14.

At this point, we are not really interested in translations of the way that certain TZIDs would have been named in the past; it is enough of a problem to get the present-day names!

* I don't understand the syntax of the examples starting <ldml><dates>....

The first line just lists the XML elements and attributes that are common to the languages. The following lines list different translations. The locales using each translation are listed surrounded by dots. The locale format is described in http://www.unicode.org/reports/tr35/. Briefly, in all the cases mentioned it is language_code ("_" script_code)? ("_" territory_code)? // Perl notation where the language code is the ISO 639 code. Thus en is English, fi is Finnish, zh is Chinese, etc.

* Re "Note: the Olson TZIDs uses the opposite sign as RFC 822 with GMT formats". This is because the Olson TZIDs use the same sign as POSIX TZ settings.

* "They are organized by cities" -> "They are organized by compact locations, typically cities." Sometimes they're islands or bases.

good notes, thanks

As far as the requests go (in part F):

I hope you'll have patience with me on this, as I learn more about the structure.

* "A list of the set of links to not skip". These would be all the Link lines that are mentioned in zone.tab.

Good.

* "The addition of unique TZIDs corresponding to the 'missing' ISO country codes BV, HM". We've discussed this. These areas are uninhabited and have no local time, so it's questionable that they need TZIDs.

I agree that these are little rocks, of no value. So it is very odd that they are given their own country codes by ISO. However, a lot of software is driven by those ISO codes, so having them be missing may be a problem. Have to look more into this.

By the way, there's one other 'missing' ISO country code that I just discovered: AX, for the Aaland Islands. (AX was added on February 13 but nobody told us. :-) I'll add a new TZID Europe/Mariehamn for it, in my next proposed tz update. It'll be an alias for Europe/Helsinki.

Thanks.

* "A mapping from some private-use ISO country code to the Etc/GMT* TZIDs."

The Olson Etc/GMT* TZIDs are pretty much a subset of POSIX, which allows an essentially unlimited set of time zone IDs. Most of the POSIX TZIDs will never be used in practice; conversely, the Olson Etc/GMT* TZIDs do not suffice (for example, they don't suffice for Los Angeles, or for India).

I'm not sure it makes sense to single out the Etc/GMT* IDs. Perhaps you need a way to specify any POSIX ID instead.

We certainly don't want all the POSIX IDs; as you say, they won't be used in practice. The only reason for including the Etc/GMT* IDs would be if they are needed. I had thought that to get all the timezones that are in use in the world, including those in international waters, wouldn't we have to include the Etc/GMT* ones? Or is this wrong?