<i18n dev> RFR JDK-8013386: (tz) Support tzdata2013c
xueming.shen at oracle.com
Thu May 9 16:24:57 PDT 2013
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.
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.
The update also included the two changes needed to fix/workaround the following 2
issues found during running the regression test
due to the changes for Rule Palestine and the corresponding Zone Asia/Gaza and
(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) 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 . 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.
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/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.
> On 08/05/2013 23:20, Xueming Shen wrote:
>> 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.
More information about the i18n-dev