RFR JDK-8013386: (tz) Support tzdata2013c

[Seán Coffey]

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