Time Zone Localizations
Mark Davis
mark.davis at jtcsv.com
Sun Jun 13 23:57:54 UTC 2004
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 at Sun.COM>
To: "Mark Davis" <mark.davis at jtcsv.com>
Cc: <tz at 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 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/formatting/tim
e
>>>>
>>>>
>_
>
>
>>>>
>>>>
>>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