Re: [tz] tzdata2016g missing version information
Hi, On 09/29/2016 08:590 AM, Eggert, Paul wrote:
Yes, it appears that the Oracle software assumed that the Makefile would have a VERSION line that specifies the version number. That assumption was never documented or guaranteed and is no longer valid. >Perhaps you can work around the problem by modifying the Makefile to say "VERSION = 2016g" (I don't have the Oracle software and so can't easily test this).
We are discussing a better way to address this problem in the future.
@Paul Eggert: The Oracle Timezone Update Tool can be downloaded from here: http://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme.... This tool has two ways of updating the timezone database: 1. Online where the timezone database is downloaded from: -l http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz 2. Offline where the timezone database is loaded locally: -l file:///tmp/tzdata2016g.tar.gz 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? I need to test the Oracle Timezone Updater Tool as soon as possible because I have customers with critical systems dependent on the time zone database. @Susan Abraham: I don't know if you are involved with the Timezone Updater Tool but this tool currently can't update the timezone because the database doesn't contain the VERSION information. @Kim Davies: I am adding you to keep you directly in the loop. Best regards, Pete -- This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
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>.
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@verint.com Web www.verint.com -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>. -- This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
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 : https://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz 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#o... regards, Sean. 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@verint.com Web www.verint.com
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>.
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. Debbie
On Oct 4, 2016, at 7:23 AM, Sean Coffey <sean.coffey@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 : https://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz
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#o...
regards, Sean.
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@verint.com Web www.verint.com
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>.
Hi Deborah and Sean, You can use the attached files with the Oracle TimeZone Update in the following way: java -jar C:\tzupdater\tzupdater.jar -v -l file:///c:/tzupdater/tzdata2016g.tar.gz I was able to update 3 JREs on machine successfully using this method. Best regards, Pete -----Original Message----- From: Deborah Goldsmith [mailto:goldsmit@apple.com] Sent: Tuesday, October 04, 2016 7:01 PM To: Sean Coffey <sean.coffey@oracle.com> Cc: Dempsey, Peter <Peter.Dempsey@verint.com>; Paul Eggert <eggert@cs.ucla.edu>; Time Zone Mailing List <tz@iana.org>; susan.abraham@oracle.com Subject: Re: [tz] tzdata2016g missing version information 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. Debbie
On Oct 4, 2016, at 7:23 AM, Sean Coffey <sean.coffey@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 : https://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz
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#o...
regards, Sean.
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@verint.com Web www.verint.com
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>.
-- This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
Thanks Pete. That would work fine also - as long as people choose to trust distributions from mailing lists! regards, Sean. On 04/10/2016 17:26, Dempsey, Peter wrote:
Hi Deborah and Sean,
You can use the attached files with the Oracle TimeZone Update in the following way:
java -jar C:\tzupdater\tzupdater.jar -v -l file:///c:/tzupdater/tzdata2016g.tar.gz
I was able to update 3 JREs on machine successfully using this method.
Best regards,
Pete
-----Original Message----- From: Deborah Goldsmith [mailto:goldsmit@apple.com] Sent: Tuesday, October 04, 2016 7:01 PM To: Sean Coffey <sean.coffey@oracle.com> Cc: Dempsey, Peter <Peter.Dempsey@verint.com>; Paul Eggert <eggert@cs.ucla.edu>; Time Zone Mailing List <tz@iana.org>; susan.abraham@oracle.com Subject: Re: [tz] tzdata2016g missing version information
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.
Debbie
On Oct 4, 2016, at 7:23 AM, Sean Coffey <sean.coffey@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 : https://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz
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#o...
regards, Sean.
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@verint.com Web www.verint.com
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>.
On 04/10/2016 17:00, Deborah Goldsmith wrote:
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. Thanks Debbie. Unfortunately, the bundle is also distributed as : tzdata-latest.tar.gz
Some people prefer to use that link for automation purposes. regards, Sean.
Debbie
On Oct 4, 2016, at 7:23 AM, Sean Coffey <sean.coffey@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 : https://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz
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#o...
regards, Sean.
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@verint.com Web www.verint.com
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>.
On Oct 4, 2016, at 12:00 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
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.
Debbie
On Oct 4, 2016, at 7:23 AM, Sean Coffey <sean.coffey@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).
Fwiw, my timezone lib (https://github.com/HowardHinnant/date) is now using the first mention of “Release” out of NEWS to get the version. This is a temporary hack (that works) until a new tzdata release establishes a VERSION file (or whatever it establishes). Howard
On 10/04/2016 09:00 AM, Deborah Goldsmith wrote:
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.
Yes, that's been true for a while, so installers should be able to rely on it. As for the 'version' file, it's been a while and as nobody has come up with anything better and simpler, attached is a proposed change to document the status quo since 2016h so that it can be relied on.
Paul, thanks for the update. I think the version file approach works well and it's good to have it documented. Oracle has a bug record[1] tracking the version issue in TZUpdater tool and we'll now take steps to address the issue and have the tool reference this new version file. regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8166928 On 09/11/2016 23:28, Paul Eggert wrote:
On 10/04/2016 09:00 AM, Deborah Goldsmith wrote:
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.
Yes, that's been true for a while, so installers should be able to rely on it.
As for the 'version' file, it's been a while and as nobody has come up with anything better and simpler, attached is a proposed change to document the status quo since 2016h so that it can be relied on.
On 2016-11-10 02:25, Seán Coffey wrote:
thanks for the update. I think the version file approach works well and it's good to have it documented. Oracle has a bug record[1] tracking the version issue in TZUpdater tool and we'll now take steps to address the issue and have the tool reference this new version file. [1] https://bugs.openjdk.java.net/browse/JDK-8166928
Would be good to heed Kevin Brown's comment about checking for the version file in the archive and falling back to the Makefile VERSION definition, to allow tests using old as well as new archives to work, without keeping both old and new jars around. Also gives customers more time to remove their workaround processes back to using only the tar and the jar. ;^p -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Hi, 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]. Regards, Ramanand. -----Original Message----- From: Sean Coffey Sent: Tuesday, October 04, 2016 7:54 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Paul Eggert <eggert@cs.ucla.edu>; Time Zone Mailing List <tz@iana.org> Cc: Susan Abraham <susan.abraham@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 : https://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz 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#o... regards, Sean. 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@verint.com Web www.verint.com
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, October 03, 2016 6:40 PM To: Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: susan.abraham@oracle.com; kim.davies@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>.
Hi Paul, Thank you for the update. Can we expect this to happen by next release ? Regards, Ramanand. -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Sunday, October 23, 2016 12:17 PM To: Ramanand Patil <ramanand.patil@oracle.com>; Sean Coffey <sean.coffey@oracle.com>; Dempsey, Peter <Peter.Dempsey@verint.com>; Time Zone Mailing List <tz@iana.org> Cc: Susan Abraham <susan.abraham@oracle.com> Subject: Re: [tz] tzdata2016g missing version information Ramanand Patil wrote:
"We plan to figure out some way of providing the version information in a documented and supported way."
That hasn't happened yet; we haven't had time.
participants (7)
-
Brian Inglis -
Deborah Goldsmith -
Dempsey, Peter -
Howard Hinnant -
Paul Eggert -
Ramanand Patil -
Sean Coffey