Hi Sherman,
Sorry for my late reply.
The fix looks ok to me.
But please remember to file an RFE about the hardcoded timezone IDs that
Masayoshi mentioned. :-)
>> I'm concerned about the 24:00 fix. Is there any way to produce the correct
rules without hard coding time zone IDs?
> I don't know how to do it, yet. I definitely can have a RFE for it and spend
some time on it later.
Thanks,
--
Yuka
(2013/05/14 2:22), Xueming Shen wrote:
It would be appreciated if you guys can help review before 5/15 us time here,
so tz
update can get into M7, if it matters;-)
-Sherman
On 5/8/2013 3:20 PM, Xueming Shen wrote:
Hi,
Please help review the proposed change to update the tz data
in JDK8 from 2012i to 2013c.
Other than the tzdb data file update under make/sun/javazic/tzdata,
corresponding updates have also been made in TimeZoneNames***.java
for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya)
test/java/util/TimeZone/tools/share/Make has been run to generate the
new test data at TimeZoneData.
# I have to update the displaynames.txt "manually" to undo the change
for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both
in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
definition in TimeZoneNames.java (which has FKT as the standard name and
FKST as the summer name) does not match the tz data file (which suggests
that Stanley has moved to use only summer zone), but since this appears
to be an existing issue that not related to this update, I keep the test data
for
Stanley untouched.
Tests list below have been run and passed.
java/util/TimeZone
java/util/Calendar
java/util/Formatter
java/time
closed/java/util/TimeZone
closed/java/util/Calendar
webrev:
http://cr.openjdk.java.net/~sherman/8013386/webrev/
http://cr.openjdk.java.net/~sherman/8013386/test.closed/
Thanks!
Sherman
