Re: RFR: 8151876: (tz) Support tzdata2016d
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.
Re: RFR: 8151876: (tz) Support tzdata2016d
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.
Re: RFR: 8151876: (tz) Support tzdata2016d
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.
Re: Review Request for JDK-8145136:Upgrade CLDR locale data
Hi Rachna, Here are my comments to the webrev (I am assuming the tool that extracts JavaTime*.java are working correctly, i.e., have not reviewed the data itself): - (All JavaTime*.java files): Unicode copyright notice is outdated. It should include the one that has "1991-2016" as the copyright year. So as the file "unicode-license.txt" - JavaTimeSupplementary_iw.java has the copyright year of "2016,". It should be "2013, 2016,". Others look OK. Naoto On 5/26/16 4:30 AM, Rachna Goel wrote: Hi all, Please review fix for JDK-8145136. Bug: https://bugs.openjdk.java.net/browse/JDK-8145136 webrev: http://cr.openjdk.java.net/~nishjain/rachna/CLDR29/8145136/webrev.00/ Fix: Currently JDK supports CLDR V27 which is upgraded to latest version 29. For more info: http://cldr.unicode.org/
Re: RFR: 8151876: (tz) Support tzdata2016d
CLDR locale data defines time zone names, like this (in en.xml): Almaty Time Almaty Standard Time Almaty Summer Time 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.
