<i18n dev> RFR JDK-8013386: (tz) Support tzdata2013c
masayoshi.okutsu at oracle.com
Fri May 10 04:57:20 UTC 2013
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?
On 5/10/2013 8:24 AM, Xueming Shen wrote:
> Hi Sean,
> Thanks for the review. It appears I missed
> 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
> Asia/Hebron .
> (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
>> 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
>>> FKST as the summer name) does not match the tz data file (which
>>> 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 core-libs-dev