if (! 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
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 lo
ese test
cases 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-lib
rmat.
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
*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.net
*Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d
CLDR locale data defines time zone names, like
: 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 en.xml
CLDR locale data defines time zone names, like this (in en.xml):
Almaty Time
Almaty Standard
Time
Almaty Summer Time
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
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" f
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 (tzda
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 tzda
11 matches
Mail list logo