[tz] tzdata2016g missing version information

Sean Coffey sean.coffey at oracle.com
Tue Oct 4 14:23:38 UTC 2016

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

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 

Further information about how to create the sha512 file is available at 


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