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
