<i18n dev> RFR: 8151876: (tz) Support tzdata2016d
masayoshi.okutsu at oracle.com
Fri May 27 14:24:49 UTC 2016
This change seems to beyond my proposal that the "GMT±hh:mm" format is
used for *new* zones with the "±hh" format. But this change removes
*existing* zones which have changed to use the "±hh" format in tzdata.
Can this cause any compatibility issues?
And have we agreed to use the "GMT±hh:mm" format?
On 5/27/2016 10:19 PM, Seán Coffey wrote:
> Looks fine to me Ramanand. the recent 2016d changes have introduced
> some boundary issues for JDK rule parsing and those issues can be
> followed up in separate issues like you say.
> On 26/05/16 14:22, Ramanand Patil wrote:
>> HI all,
>> Please review the latest TZDATA integration (tzdata2016d) to JDK9.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>> Patch Contains:
>> 1. IANA tzdata2016d integration into JDK. [It also includes
>> tzdata2016b and tzdata2016c which was not integrated].
>> 2. "GMT[+ -]hh:mm" is used for formatting of the modified or
>> newly added TimeZones in tzdata2016d.
>> [This is done to accommodate the IANA's new system where the zones
>> use numeric time zone abbreviations like "+04" instead of invented
>> abbreviations like "ASTT".]
>> 3. Test case:
>> java/time/test/java/time/format/TestZoneTextPrinterParser.java is
>> updated to include the failures because of GMT[+ -]hh:mm format names.
>> 4. Few other failing tests: For few other failing tests, new
>> linked bugs are created and will be addressed in a separate patch.
More information about the i18n-dev