[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-i18n-dev
Subject: Re: <i18n dev> RFR: 8049343: (tz) Support tzdata2014f
From: Masayoshi Okutsu <masayoshi.okutsu () oracle ! com>
Date: 2014-08-28 3:43:35
Message-ID: 53FEA567.9020601 () oracle ! com
[Download RAW message or body]
src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
239 String SLST[] = new String[] {"Greenwich Mean Time", "GMT",
240 "Sierra Leone Summer Time", "SLST",
241 "Sierra Leone Time", "SLT"};
251 String WART[] = new String[] {"Western Argentine Time", "WART",
252 "Western Argentine Summer Time", "WARST",
253 "Western Argentine Time", "WART"};
It seems these are no longer used.
- {"Antarctica/Macquarie", new String[] {"Macquarie Island Time", "MIST",
- "Macquarie Island Summer Time", \
"MIST", + {"Antarctica/Macquarie", new String[] {"Macquarie Island \
Standard Time", "MIST", + \
"Macquarie Island Daylight Time", "MIST",
The daylight saving time abbreviation should be MIDT.
Thanks,
Masayoshi
On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
> Masayoshi,
> Thank you for a detailed review - I tried to address all your
> comments. Please, see the updated review:
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
> About the workarounds - I will start discussion with Sherman when the
> tzdata2014f (and I suppose the 2014g - it will be available soon
> according to tzdata mail-list [1]) integration will be complete.
>
> -Aleksej
>
> [1] tzdata2014g is coming:
> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>
> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
> > Here are additional comments.
> >
> > src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
> >
> > I'm concerned about the workarounds. It's not new in this update, but
> > this problem would make tzupdater data void until the workaround is
> > added to the next update release. Could you please work with Sherman
> > to eliminate the workaround (outside of this 2014f update)?
> >
> > src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
> >
> > String LORD_HOWE[] = new String[] {"Lord Howe Standard
> > Time", "LHST",
> > - "Lord Howe Summer Time",
> > "LHST",
> > + "Lord Howe Summer Time",
> > "LHDT",
> >
> > The S-D convention is applied to Lord Howe as well.
> >
> > 567 {"Antarctica/Macquarie", new String[] {"Macquarie
> > Island Time", "MIST",
> > 568 "Macquarie Island Summer Time", "MIST",
> > 569 "Macquarie Island Time", "MIST"}},
> >
> > This one should also follow the S-D convention, although this time
> > zone doesn't observe daylight saving time.
> >
> >
> > + String XJT[] = new String[] {"China Standard Time", "XJT",
> > + "China Daylight Time", "XJDT",
> > + "China Time", "XJT"};
> >
> > Should the long names be based on Xinjiang?
> >
> > Africa/Freetown is now a link to Africa/Abidjan. Those should be the
> > same time zone.
> >
> > - {"America/Metlakatla", new String[] {"Metlakatla
> > Standard Time", "MeST",
> > - "Metlakatla
> > Daylight Time", "MeDT",
> > - "Metlakatla Time",
> > "MeT"}},
> > + {"America/Metlakatla", new String[] {"Metlakatla
> > Standard Time", "PST",
> > + "Metlakatla
> > Daylight Time", "PDT",
> > + "Metlakatla Time",
> > "PT"}},
> >
> > - {"Europe/Volgograd", new String[] {"Volgograd Time",
> > "VOLT",
> > - "Volgograd Summer
> > Time", "VOLST",
> > - "Volgograd Time",
> > "VOLT"}},
> > + {"Europe/Volgograd", new String[] {"Volgograd Time", "MSK",
> > + "Volgograd Summer
> > Time", "MSK",
> > + "Volgograd Time",
> > "MSK"}},
> >
> >
> > The long names should be changed accordingly.
> >
> > Thanks,
> > Masayoshi
> >
> > On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
> > > Masayoshi,
> > > You're right that the "root names" should be changed as part of this
> > > update. The names were changed according to Australian official
> > > document here: http://australia.gov.au/about-australia/our-country/time
> > > The fixed version of the webrev can be found here:
> > > http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
> > >
> > > Thanks,
> > > Aleksej
> > >
> > >
> > > On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
> > > > We used to make name changes in the root (base) bundle as part of
> > > > time zone data maintenance and deter only translations. But if you
> > > > want to handle name changes later, that would be fine. It's your call.
> > > >
> > > > Thanks,
> > > > Masayoshi
> > > >
> > > > On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
> > > > > Masayoshi,
> > > > > I agree that we should change the long names to match the new
> > > > > short names introduced by tzdata.
> > > > > But I suggest to log a different CR for such activity to handle
> > > > > long name changes and their translations (this activity is
> > > > > slightly out of tzdata update scope). Does it make sense?
> > > > >
> > > > > -Aleksej
> > > > >
> > > > > On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
> > > > > > I think the long names of the Australia time zones should be
> > > > > > revisited to be consistent with the abbreviation changes. The new
> > > > > > abbreviations follow the S[tandard] and D[aylight saving]
> > > > > > convention rather than the S[tandard] and S[ummer time] one. The
> > > > > > long names, such as "Eastern Summer Time (Queensland)", no longer
> > > > > > make sense.
> > > > > >
> > > > > > On the other hand, you will need to access impact of the name
> > > > > > changes, including abbreviations. Also, if you change the long
> > > > > > names, their translations will need to be changed as well.
> > > > > >
> > > > > > Thanks,
> > > > > > Masayoshi
> > > > > >
> > > > > > On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Please, review the tzdata2014f integration (with tzdata2014e
> > > > > > > related changes included too) [1] fix to JDK9:
> > > > > > > http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
> > > > > > >
> > > > > > > The tzdata2014f changes are extensive and relates mostly to
> > > > > > > timezone short names changes + "Asia/Srednekolymsk" time zone
> > > > > > > were added.
> > > > > > > Almost complete list of changes can be found in the JBS bug
> > > > > > > description [1], plus some changes wasn't documented in tzdata
> > > > > > > release notes - for such cases raw tzdata diff was used for the
> > > > > > > names modifications.
> > > > > > >
> > > > > > > Two issues with JSR310 implementation were discovered during
> > > > > > > integration process:
> > > > > > > First issue is related to the internal representation of the
> > > > > > > '24:00' value. The JSR310 implementation treats this value as a
> > > > > > > next day 00:00 time. The workaround already exists in JSR310
> > > > > > > code for similar entries and this failure is resolved in similar
> > > > > > > way [2] as part of this update.
> > > > > > > For the second issue JDK-8051641 [3] was filled and
> > > > > > > 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one
> > > > > > > that fails with this tzdata.
> > > > > > > Other time zone related tests [4] passes without failures.
> > > > > > >
> > > > > > > Thank you,
> > > > > > > Aleksej
> > > > > > >
> > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8049343
> > > > > > > [2]
> > > > > > > http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
> > > > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8051641
> > > > > > > [4] TZ related test sets: test/sun/util/calendar
> > > > > > > test/java/util/Calendar test/sun/util/resources/TimeZone
> > > > > > > test/sun/util/calendar test/java/util/TimeZone test/java/time\
> > > > > > > test/java/util/Formatter test/closed/java/util/Calendar
> > > > > > > test/closed/java/util/TimeZone
> > > > > >
> > > > >
> > > >
> > >
> >
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic