<i18n dev> RFR: 8049343: (tz) Support tzdata2014g
Masayoshi Okutsu
masayoshi.okutsu at oracle.com
Thu Sep 4 06:33:36 UTC 2014
The fix looks OK to me.
Thanks,
Masayoshi
On 9/2/2014 10:41 PM, Aleksej Efimov wrote:
> 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