Re: RFR: 8151876: (tz) Support tzdata2016d

2016-06-01 Thread Seán Coffey
(! zi.equalsTo(ziOLD)) { Regards, Ramanand. *From:*Seán Coffey *Sent:* Tuesday, May 31, 2016 3:05 PM *To:* Masayoshi Okutsu; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.net *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d Masayoshi, I still think the test ad

RE: RFR: 8151876: (tz) Support tzdata2016d

2016-06-01 Thread Ramanand Patil
Sent: Tuesday, May 31, 2016 3:05 PM To: Masayoshi Okutsu; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8151876: (tz) Support tzdata2016d   Masayoshi, I still think the test adds value. At minimum it identifies timezones which don't have a localis

Re: RFR: 8151876: (tz) Support tzdata2016d

2016-05-31 Thread Seán Coffey
es where the entries are not present in the resources and the Short/Long display names fallback to the GMT±hh:mm format. Regards, Ramanand. *From:*Masayoshi Okutsu *Sent:* Saturday, May 28, 2016 10:58 AM *To:* Seán Coffey; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.n

RE: RFR: 8151876: (tz) Support tzdata2016d

2016-05-31 Thread Ramanand Patil
  Regards, Ramanand.   From: Masayoshi Okutsu Sent: Saturday, May 28, 2016 10:58 AM To: Seán Coffey; Ramanand Patil; HYPERLINK "mailto:i18n-...@openjdk.java.net"i18n-...@openjdk.java.net; HYPERLINK "mailto:core-libs-dev@openjdk.java.net"core-libs-dev@openjdk.java.net Subject:

Re: RFR: 8151876: (tz) Support tzdata2016d

2016-05-31 Thread Masayoshi Okutsu
ayoshi Okutsu *Sent:* Saturday, May 28, 2016 10:58 AM *To:* Seán Coffey; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.net *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d CLDR locale data defines time zone names, like this (in

Re: RFR: 8151876: (tz) Support tzdata2016d

2016-05-27 Thread Masayoshi Okutsu
CLDR locale data defines time zone names, like this (in en.xml): Almaty Time Almaty Standard Time Almaty Summer Time

Re: RFR: 8151876: (tz) Support tzdata2016d

2016-05-27 Thread Seán Coffey
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

Re: RFR: 8151876: (tz) Support tzdata2016d

2016-05-27 Thread 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"

Re: RFR: 8151876: (tz) Support tzdata2016d

2016-05-27 Thread Seán Coffey
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

RFR: 8151876: (tz) Support tzdata2016d

2016-05-26 Thread Ramanand Patil
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