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