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

[Masayoshi Okutsu]

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