[tz] tzdata2016g missing version information
goldsmit at apple.com
Tue Oct 4 16:00:58 UTC 2016
The version number is available in the name of the tar archive. Admittedly, that’s not the most convenient way to get it, but it’s there.
> On Oct 4, 2016, at 7:23 AM, Sean Coffey <sean.coffey at oracle.com> wrote:
> 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 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