FW: Time Zone Localizations
Olson, Arthur David (NIH/NCI)
olsona at dc37a.nci.nih.gov
Tue Jun 15 13:21:33 UTC 2004
Masayoshi Okutsu has been added to the time zone mailing list; this is a
message sent before Masayoshi was added.
--ado
-----Original Message-----
From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu at Sun.COM]
Sent: Sunday, June 13, 2004 8:37 AM
To: Mark Davis
Cc: tz at lecserver.nci.nih.gov
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 at 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 at Sun.COM>
>To: "Mark Davis" <mark.davis at jtcsv.com>
>Cc: <tz at 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 at Sun.COM>
>>To: "Mark Davis" <mark.davis at jtcsv.com>
>>Cc: <tz at 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 at Sun.COM>
>>>To: "Mark Davis" <mark.davis at jtcsv.com>
>>>Cc: <tz at 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/format
>>>>ting/time
>>>>
>>>>
>_
>
>
>>>>
>>>>
>>z
>>
>>
>>
>>
>>>>
>>>>
>>>one_localization.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I'd very much appreciate any feedback on the proposal.
>>>>
>>>>Mark
>>>>__________________________________
>>>>http://www.macchiato.com
>>>>► शिष्यादिच्छेत्पराजयम् ◄
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
More information about the tz
mailing list