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.
