<i18n dev> RFR: 8049343: (tz) Support tzdata2014f

[Aleksej Efimov]

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