Time Zone Localizations

Masayoshi Okutsu Masayoshi.Okutsu at Sun.COM
Sat Jun 12 00:43:55 UTC 2004


Probably you have misunderstood my first question...

Many zones have changed their time zones in their history. It's not a 
valid assumption that a single zone ID represents a single time zone. It 
may be confusing to say "zone changes time zones". Let me give you an 
example.

Here's the history of Asia/Singapore.

# 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


During 1942-02-16 until 1945-09-12, Asia/Singapore's time zone was Japan 
Standard Time (GMT+09:00). (Sorry if this isn't a good example...)

The LDML spec didn't look like supporting all historical time zones 
within a single zone. So what I'd like to see is something organized like:

<zone type="Asia/Singapore" >
  <zoneNameSet format="SGT">
    <long>
        <generic>Singapore Time</generic>
        <standard>Singapore Time</standard>
        <daylight>Singapore Time</daylight>
    </long>
    <short>
        <generic>SGT</generic>
        <standard>SGT</standard>
        <daylight>SGT</daylight>
    </short>
  </zoneNameSet>
  ...
  <zoneNameSet format="LMT">
    <long>
         <generic>Local Mean Time</generic>
         ...
    <short>
         <generic>LMT</generic>
         ...
  </zoneNameSet>
    <exemplarCity>Singapore</exemplarCity>
</zone>

Obviously use of this structure involves redundant names. Probably it 
should have all name sets which can be referred to by <zone>.

I got several bug reports on Java time zone support because it supports 
all historical changes since 1.4. Some customers were just confused with 
historically correct local time. Some of them could have been avoided if 
Java was capable of giving historically correct time zone names.

Hope my question is now clearer.

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/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