<i18n dev> RFR JDK-8013386: (tz) Support tzdata2013c
xueming.shen at oracle.com
Fri May 10 06:30:04 UTC 2013
On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
> Do we still need to keep the old javazic code in JDK8? It's a
> maintenance burden to maintain both, isn't it?
While it's a burden, but somehow it serves as a test case pretty well.
The transitions are
being built the "old" jdk way and threeten way, if the transition does
not match, something
might be wrong. This time, it's in the "old" code, maybe next time it's
in the threeten. So
it might be still worth keeping a while, to remove in jdk9? Btw, the
Rule.java fix might need
go into the tzdb update tool as well, I believe the transitions for 2011
Palestine are wrong in
the updated tzdb updator.
> 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
> 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 :
>>> (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
>>> 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
>>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why
>>>> 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
>>>> that Stanley has moved to use only summer zone), but since this
>>>> 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