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

[Aleksej Efimov]

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
>