<i18n dev> RFR: 8049343: (tz) Support tzdata2014f
Aleksej Efimov
aleksej.efimov at oracle.com
Wed Aug 27 13:53:17 UTC 2014
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
>>>>>
>>>>
>>>
>>
>
More information about the i18n-dev
mailing list