<i18n dev> RFR: 8049343: (tz) Support tzdata2014g
Michael Fang
michael.fang at oracle.com
Wed Sep 3 06:07:52 UTC 2014
Aleksej,
Yes, I agree the translation update of the time zone names can be
handled separately as JDK-8057004.
thanks,
-michael
On 14年09月01日 07:10 上午, 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