Time Zone Localizations
Masayoshi Okutsu
Masayoshi.Okutsu at Sun.COM
Mon Jun 14 06:18:35 UTC 2004
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 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