FW: Time Zone Localizations

Tue Jun 15 13:21:18 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: Saturday, June 12, 2004 10:35 AM
To: Mark Davis
Cc: tz at lecserver.nci.nih.gov
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/formatt
>>>ing/time_
>>>      
>>>
>z
>  
>
>>>      
>>>
>>one_localization.html
>>
>>
>>    
>>
>>>I'd very much appreciate any feedback on the proposal.
>>>
>>>Mark
>>>__________________________________
>>>http://www.macchiato.com
>>>► शिष्यादिच्छेत्पराजयम् ◄
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>
>>
>>    
>>
>
>
>
>  
>