<i18n dev> RFR JDK-8013386: (tz) Support tzdata2013c

Fri May 10 02:57:44 PDT 2013

On 5/10/2013 3:30 PM, Xueming Shen wrote:
> 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.

Yes, the Rule.java fix needs to go to older JDKs and TZ updater (build 
system).

Masayoshi

>
>> 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.
>
> -Sherman
>
>>
>> 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
>>>>
>>>
>>
>