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

[Masayoshi Okutsu]

CLDR locale data defines time zone names, like this (in en.xml):

                        <metazone type="Almaty">
                                 <long>
                                         <generic>Almaty Time</generic>
                                         <standard>Almaty Standard Time</standard>
                                         <daylight>Almaty Summer Time</daylight>
                                 </long>
                         </metazone>

The CLDR converter tool tries to fill in the missing short names from 
the legacy TimeZoneNames data. Removing existing names causes some 
unexpected behavior. I think JDK-8157814 is an example of the unexpected 
behavior. And the suggested fix in JDK-8157814 looks to me like a 
workaround.

I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Seán Coffey wrote:
> I guess there's a low risk of timezone not being identified if being 
> parsed in through a formatter. Isn't such an approach discouraged 
> though ? short IDs were already subject to change in tzdata releases. 
> Ramanand found one issue by removal of these resource strings (so far) 
> and that's captured in JDK-8157814
>
> There's a decision to be made about how to use the GMT±hh:mm format 
> for new releases given IANA's new short ID identifier mechanism. I 
> think that could be discussed as a separate issue. I'd like to see us 
> follow a similar approach to IANA and use GMT identifiers on new 
> timezones and perhaps even consider using the IANA long name format 
> also for the getDisplayName(..) calls that can be made. e.g. 
> "Asia/Almaty" instead of "Alma-Ata Time"
> Regards,
> Sean.
> On 27/05/16 15:24, Masayoshi Okutsu wrote:
>> 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.
>>>>
>>>
>>
>