<i18n dev> RFR: 8049343: (tz) Support tzdata2014g
Aleksej Efimov
aleksej.efimov at oracle.com
Mon Sep 1 14:10:44 UTC 2014
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