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
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
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
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 copyri
CLDR locale data defines time zone names, like this (in en.xml):
Almaty Time
Almaty Standard
Time
Almaty Summer Time
