[tz] tzdata2016g missing version information

Ramanand Patil ramanand.patil at oracle.com
Sun Oct 23 04:49:21 UTC 2016


With the release of tzdata2016h, we can see the "version" file is also included in the tar bundle- tzdata2016h.tar.gz and the same is mentioned in the announcement mail and NEWS file.
As per the earlier mail conversation (http://mm.icann.org/pipermail/tz/2016-October/024266.html ), Paul mentioned: "We plan to figure out some way of providing the version information in a documented and supported way."

Can NEWS file be considered as an official change document? If not where this change is documented or will be documented?

[This information is crucial to modify the TZUpdater tool functionality].


-----Original Message-----
From: Sean Coffey 
Sent: Tuesday, October 04, 2016 7:54 PM
To: Dempsey, Peter <Peter.Dempsey at verint.com>; Paul Eggert <eggert at cs.ucla.edu>; Time Zone Mailing List <tz at iana.org>
Cc: Susan Abraham <susan.abraham at oracle.com>
Subject: Re: [tz] tzdata2016g missing version information

Removal of the VERSION field in the Makefile is a surprising development and seems to have broken a few systems (including the Oracle TZUpdater tool).

The change was documented via the following addition to the NEWS file :
>     The release version number is now more accurate in the usual case
>     where releases are built from a Git repository.  For example, if
>     23 commits and some working-file changes have been made since
>     release 2016g, the version number is now something like
>     '2016g-23-g50556e3-dirty' instead of the misleading '2016g'.
>     Official releases uses the same version number format as before,
>     e.g., '2016g'.  To support the more-accurate version number, its
>     specification has moved from a line in the Makefile to a new
>     source file 'version'.

The argument that the legacy VERSION field may be inaccurate doesn't make sense for the official tzdataxxxx.tar.gz bundles released by IANA. 
These are official
snapshots of a promoted release and as such should have a clear mechanism to help end users identify the version value. Perhaps that field should be populated at build time (only) when each official tzdata version is being bundled and 'promoted' to release status.

Putting the value in a separate release bundle doesn't help matters for those frameworks that work solely with the tzdata.tar.gz distribution bundles. Adding the value as an entry to the NEWS file doesn't seem optimal either. I look forward to hearing from the tzdata maintainers about how such version parsing logic will be supported in future tzdata releases. Judging from the issues reported to date, this change has had a wide enough impact for people working with tzdata.

In the interim, I've included more information below about how users of the Oracle TZUpdater tool can work around this issue. I hope to get this issue noted in the relevant TZUpdater README also.


Download the recently released tzdata.tar.gz file :

Extract the file to a local directory and modify the Makefile.

Change :
VERSION=        unknown
to :
VERSION=        2016g

tar up contents of the directory to create tzdata2016g.tar.
gzip the tar file to reproduce the tzdata2016g.tar.gz file.

Run the TZUpdater tool with the -l <URL resource> option where 'URL resource' points at the newly created tzdata2016g.tar.gz file. A corresponding SHA-512 checksum file will need to be created in the same directory that's hosting the new .gz file. It needs to contain the
SHA-512 hash calculated from the gz file contents.

e.g. <JDK_HOME>/bin/java -jar tzupdater.jar -l file:///tmp/tzdata/tzdata2016g.tar.gz

Further information about how to create the sha512 file is available at http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html#override


On 04/10/2016 13:16, Dempsey, Peter wrote:
> Hi Paul,
> I was able to modify the Makefile as you suggested and rebuilt the .tar.gz on Windows successfully. The Oracle Time zone updater tool was then able to successfully updated the time zone and I wrote a simple Java application to test the time zone.
> Best regards,
> Pete
> Pete Dempsey
> Application Engineer
> Verint Customer Engagement Solutions
> Phone +90.532.581.5995
> Email   peter.dempsey at verint.com
> Web     www.verint.com
> -----Original Message-----
> From: Paul Eggert [mailto:eggert at cs.ucla.edu]
> Sent: Monday, October 03, 2016 6:40 PM
> To: Dempsey, Peter <Peter.Dempsey at verint.com>; Time Zone Mailing List 
> <tz at iana.org>
> Cc: susan.abraham at oracle.com; kim.davies at icann.org
> Subject: Re: tzdata2016g missing version information
> On 10/03/2016 02:17 AM, Dempsey, Peter wrote:
>> The tzdata file published on the IANA site needs to include the 
>> VERSION information so that this tool can work. When do you think 
>> this can be provided?
> The version information is provided in the time zone distribution now.
> It's just not in the (old, undocumented, and flaky) form that the Oracle tool was expecting. We plan to figure out some way of providing the version information in a documented and supported way. When that happens, the current Oracle tool likely still won't work, because it won't support whatever way we develop. So it will need to be modified as well. When all this happens, everything will start working nicely again.
> There is no schedule for this: among other things I do not set Oracle's schedule and as far as I know nobody has written or tested any code yet.
> Please remember that this is a volunteer project. In the meantime you can use the workaround I mentioned in <http://mm.icann.org/pipermail/tz/2016-September/024221.html>.

More information about the tz mailing list