Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
I'm concerned about the 24:00 fix. Is there any way to produce the
correct rules without hard coding time zone IDs?
Masayoshi
On 5/10/2013 8:24 AM, Xueming Shen wrote:
Hi Sean,
Thanks for the review. It appears I missed
jdk/test/sun/util/calendar/zi/tzdata,
webrev has been updated to include the test data update.
http://cr.openjdk.java.net/~sherman/8013386/webrev
I will update TCKZoneRulesProvider.java separately in JSR310 repo,
this def is
actually is not being used by anyone anymore, just need to be removed.
jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be
removed, I
will remove it separately later.
Masayoshi,
The update also included the two changes needed to fix/workaround the
following 2
issues found during running the regression test
jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,
due to the changes for Rule Palestine and the corresponding Zone
Asia/Gaza and
Asia/Hebron [1].
(1) Now the Rule Palestine has the def of "lastThu 24:00", similar to
Asia/Amman, so
these two zones need to be handled specially in ZoneInfoFile as well [2]
(2) Rule Palestine has 2 day-saving changes in 2011, so it has 4
transitions for 2011
when returned from Rule.getRules(int year). Unfortunately it appears
the Comparator
for Arrays.sorting is incorrectly implemented when comparing two longs
[3]. The directly
consequence of this decade-old bug is that the returned list has the
wrong order for
2011/08/01/xxx and 2011/08/30/xxx
Please help review.
Thanks!
-Sherman
[1]
http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
[2]
http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
[3]
http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html
On 05/09/2013 02:06 AM, Seán Coffey wrote:
Thanks for taking care of this Sherman. I was wondering what sort of
impact JSR 310 would make on tzdata updates. The Atlantic/Stanley
display name issue mentioned is a regular one, we should log a bug
against the test file generation scripts.
I just had a quick grok of the jdk8 repo. The following files need
updating also :
jdk/test/sun/util/calendar/zi/tzdata/*
jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line
85)
jdk/makefiles/GendataTimeZone.gmk (line 29)
It looks like jdk/makefiles/GendataTimeZone.gmk still has a
dependency on reading files from jdk/make. That'll all have to change
too once the old build system is removed from jdk8. I think the new
tzdata sources should be moved into a directory under makefiles
rather than keeping them in make.
The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in
jdk/makefiles/GendataTimeZone.gmk should be removed if we know that
the version string can be read from the VERSION file stored with tzdata.
Above points are not necessarily related to 2013c update and should
be cleaned up separately perhaps.
regards,
Sean.
On 08/05/2013 23:20, 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
