<i18n dev> RFR: 8151876: (tz) Support tzdata2016d

[Masayoshi Okutsu]

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?

Thanks,
Masayoshi


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.
>
> Regards,
> Sean.
>
> 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.
>>
>>
>> Regards,
>>
>> Ramanand.
>>
>