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...
_
z
one_localization.html
I'd very much appreciate any feedback on the proposal.
Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄