Aleksej,
Yes, I agree the translation update of the time zone names can be
handled separately as JDK-8057004.
thanks,
-michael
On 14年09月01日 07:10 上午, Aleksej Efimov wrote:
Masayoshi,
I have addressed all your comments with proposed resolution. Thank you
for such thorough analysis of this changes.
Also the new tzdata is out (2014g) - I have updated the JBS bug by
adding 2014g related change notes and renamed this bug appropriately +
I'm renaming this thread.
The new webrev contains new changes related to 2014g:
- {"America/Grand_Turk", EST},
+ {"America/Grand_Turk", AST},
The 2014e/f related changes, discussed previously, are still in place.
New webrev can be found here:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
The bug for the incomplete localization of new/updated time zone names
was filed: https://bugs.openjdk.java.net/browse/JDK-8057004
With Best Regards,
Aleksej
On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
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
