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

[Masayoshi Okutsu]

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