FW: Time Zone Localizations
Olson, Arthur David (NIH/NCI)
olsona at dc37a.nci.nih.gov
Tue Jun 15 13:21:40 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: Monday, June 14, 2004 2:21 AM
To: Mark Davis
Cc: tz at lecserver.nci.nih.gov
Subject: Re: Time Zone Localizations
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/forma
>>>>>tting/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