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?