<i18n dev> RFR: 8049343: (tz) Support tzdata2014f
Masayoshi Okutsu
masayoshi.okutsu at oracle.com
Thu Aug 28 03:43:35 UTC 2014
src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
239 String SLST[] = new String[] {"Greenwich Mean Time", "GMT",
240 "Sierra Leone Summer Time", "SLST",
241 "Sierra Leone Time", "SLT"};
251 String WART[] = new String[] {"Western Argentine Time", "WART",
252 "Western Argentine Summer Time", "WARST",
253 "Western Argentine Time", "WART"};
It seems these are no longer used.
- {"Antarctica/Macquarie", new String[] {"Macquarie Island Time", "MIST",
- "Macquarie Island Summer Time", "MIST",
+ {"Antarctica/Macquarie", new String[] {"Macquarie Island Standard Time", "MIST",
+ "Macquarie Island Daylight Time", "MIST",
The daylight saving time abbreviation should be MIDT.
Thanks,
Masayoshi
On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
> 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