June 2004 - tz - lists.iana.org

Re: 64-bit time_t must go--this is non-negotiable
by Paul Eggert June 18, 2004

June 18, 2004

matthew green <mrg(a)eterna.com.au> writes: > actually, no NetBSD platform uses a 64 bit time_t on any of the > several 64 bit machines it runs on. Sorry, my mistake. Thanks for correcting me. I was told in 1995 that NetBSD on Alpha used a 64-bit time_t, and never bothered to check (nor has anyone else corrected me despite my reporting this on Usenet for almost a decade, e.g., see <http://groups.google.com/groups?selm=51ke97%2452d%40deck.twinsun.com>). I just checked Usenet, and FreeBSD started talking about the change to 64-bit time_t in 2001 and decided to do it one architecture at a time (sparc64 made the transition earlier this year). They're even making noises about using 64-bit time_t for x86, though that sounds a bit extreme. So I should have written "FreeBSD on some architectures" rather than "the BSDs".

2 1

RE: zdump -v crashes with 64-bit time_t
by Olson, Arthur David (NIH/NCI) June 17, 2004

June 17, 2004

> * Don't attempt to print out all the 64-bit time_t space, as that will > take nearly forever; instead, default to printing about 50 years > into the future, and don't bother to print times before about 1833. It might be better to cut off at something such as... 2050 + 100 * ((current_year - 1930) / 100) ...to ease regression testing; this would maintain a cutoff of 2050 until 2030, then boost the cutoff to 2150 until 2130, and so on. This way zdump output only changes every hundred years; the next change is set for eight years before 2038 and the miseries associated with T4G (you read the abbreviation here first) to provide ample time to catch bugs, while avoiding any output changes for the next 26 years. --ado

2 1

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Monday, June 14, 2004 2:21 AM To: Mark Davis Cc: tz(a)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(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)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(a)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(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)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(a)Sun.COM> >>>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>>Cc: <tz(a)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(a)Sun.COM> >>>>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>>>Cc: <tz(a)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 >>>>>► शिष्यादिच्छेत्पराजयम् ◄ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Sunday, June 13, 2004 8:37 AM To: Mark Davis Cc: tz(a)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(a)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(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)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(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)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(a)Sun.COM> >>>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>>Cc: <tz(a)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 >>>>► शिष्यादिच्छेत्पराजयम् ◄ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Saturday, June 12, 2004 10:35 AM To: Mark Davis Cc: tz(a)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(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)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(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)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 >>>► शिष्यादिच्छेत्पराजयम् ◄ >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Friday, June 11, 2004 8:44 PM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations 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(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)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(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)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 >>>► शिष्यादिच्छेत्पराजयम् ◄ >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Friday, June 11, 2004 11:42 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov 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(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)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/formatti >>ng/time_z >> >> >one_localization.html > > >>I'd very much appreciate any feedback on the proposal. >> >>Mark >>__________________________________ >>http://www.macchiato.com >>► शिष्यादिच्छेत्पराजयम् ◄ >> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Friday, June 11, 2004 10:50 AM To: Chuck Soper Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations Chuck Soper wrote: > Are these tables informational or vital to the process? For example, > will the Aliases table be used to "Canonicalize the Olson ID" (step 1 > of the Fallback procedure)? If so, then the table should be based on > the current time zone data files instead of "current Java data". This > could turn into a serious maintenance issue. Ideally, I think that a > script could be run on the time zone data files to generate a new > aliases table each time the time zone data files are updated > (currently tzdata2004a). I agree. And it's unclear what the "current Java data" is. *My* current Java data is tzdata2004a, which is very unlikely to be shipped with 1.5... > Where did AET (line 2, Aliases table) for Australia/Sydney come from? > I can't find any reference to it in tzdata2004a. I guess it came from JDK1.1 compatibility names. Someone (not me!) invented 3-letter time zone IDs in JDK 1.1, which failed to support more time zones. Java uses the Olson zone IDs since 1.2. But we still have the JDK 1.1 compatibility names as far as they don't conflict with any Olson zone IDs. > ### Equivalent Modern Zones > My first reaction whenever I see a significant effort to simplify > something for the user is to think that it could lead to problems. I tend to agree with you. I think we should find out another way to reduce the number of localized time zone name strings. > How did you determine that "A lot of people just don't care about > historic differences"? Do most people use time zones merely to keep > track of the current time or current differences between another time > zone? How else do users use time zones? Right. And how can we define "current" for time zones which change their offsets some time in the future, like America/Mendoza in tzdata2004a? The day after tomorrow...? :-) Masayoshi

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 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@Sun.COM] Sent: Friday, June 11, 2004 9:43 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov 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/formattin >g/time_zone_localization.html > >I'd very much appreciate any feedback on the proposal. > >Mark >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > > > >

1 0

IERS Message No. 58: IERS Conventions Center: New discussion foru m and web site.
by IERS Central Bureau June 15, 2004

June 15, 2004

*************************************************************************** IERS Message No. 58 June 15, 2004 *************************************************************************** IERS Conventions Center: New discussion forum and web site. The IERS Conventions center has developed a Discussion Forum and a new web and ftp site for the IERS Conventions, on a server at the BIPM. 1) The user discussion forum http://tai.bipm.org/iers/forum/ is open for users to offer their comments, criticism, and suggestions regarding the update of the IERS Conventions. It is organized in themes following the present structure of the IERS Conventions (2003). To post a contribution it is necessary to be registered. Registration is a very simple procedure. It is only necessary to provide a login_name and password, and a valid e-mail address. It is recommended that the login_name be representative of your real name because the login_name is used to identify the authors of contributions. Reading the contributions is open and anonymous. A number of contributions have been posted in advance of the public opening by Jim Ray in order to stimulate discussions. Responses and new contributions are welcome. 2) The new ftp site ftp://tai.bipm.org/iers/ has two directories: * ftp://tai.bipm.org/iers/conv2003/ is a mirror of the usual ftp site ftp://maia.usno.navy.mil/conv2003/ containing all files of the Conventions (2003) (Note that as of June 4, 2004 the pdf files of the chapters have not been updated on the USNO site). * ftp://tai.bipm.org/iers/convupdt/ is used to store material relative to future updates of the IERS Conventions. 3) The new web site http://tai.bipm.org/iers/ has two main pages: * http://tai.bipm.org/iers/conv2003/conv2003.html which ultimately points to the material of the Conventions (2003). * http://tai.bipm.org/iers/convupdt/convupdt.html which is used for Conventions updates. It is planned to save all the information on successive updates incrementing in the pages of each chapter. See an example version in http://tai.bipm.org/iers/convupdt/convupdt_c5.html Gérard Petit and Dennis D. McCarthy IERS Conventions Center *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0