<i18n dev> RFR: 8049343: (tz) Support tzdata2014g
Aleksej Efimov
aleksej.efimov at oracle.com
Tue Sep 2 13:41:13 UTC 2014
Masayoshi,
Sorry for the confusion - for some reason (most probably this change was
added after webrev generation) I forgot to include it. Now it's in
place: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
Thank you,
Aleksej
On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote:
> Aleksej,
>
> I don't see the America/Grand_Turk change in webrev.04. I wonder if
> the webrev wasn't updated correctly.
>
> Thanks,
> Masayoshi
>
> On 9/1/2014 11:10 PM, Aleksej Efimov wrote:
>> Masayoshi,
>>
>> I have addressed all your comments with proposed resolution. Thank
>> you for such thorough analysis of this changes.
>>
>> Also the new tzdata is out (2014g) - I have updated the JBS bug by
>> adding 2014g related change notes and renamed this bug appropriately
>> + I'm renaming this thread.
>> The new webrev contains new changes related to 2014g:
>> - {"America/Grand_Turk", EST},
>> + {"America/Grand_Turk", AST},
>>
>>
>> The 2014e/f related changes, discussed previously, are still in place.
>>
>> New webrev can be found here:
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
>>
>> The bug for the incomplete localization of new/updated time zone
>> names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004
>>
>> With Best Regards,
>> Aleksej
>>
>> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
>>> 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