Re: [tz] from tzdata2020a to tzdata2020b: iana, tzupdater, or local issue?
On 10/13/20 2:07 AM, gerar.moisset@orange.com wrote:
I'd like to know why we are obliged to patch tzdata2020b-rearguard.tar.gz?
It's because TZUpdater uses tzdb internals that are not documented under "Interface stability" <https://data.iana.org/time-zones/theory.html#stability>, and when these internal details are changed, TZUpdater sometimes fails.
For us impact is it breaks automatic tz update. Does it mean we need to leave this kind of tz update?
As noted in <https://mm.icann.org/pipermail/tz/2020-October/029340.html> there will be a workaround in the next tzdb release, which should be reasonably soon, so one option is to wait until tzdb 2020c comes out and try its rearguard tarball. That being said, there's little coordination between the maintainers of tzdb and of TZUpdater, and as far as I know nobody has tested this specific workaround code. (You might be the first one to try it when 2020c comes out. :-)
Does it come from iana src content ? If not we are not obliged to reply, but I’d like to understand, does it come from tzupdater, or kind of jdk, or jdk version?
It's an incompatibility between tzdb (as published by IANA) and TZUpdater (maintained by Oracle).
tzupdater-2.2.0,
TZUpdater 2.3.1 is out, and you might want to update to it for other reasons. However, I expect that it has the same problem here that 2.2.0 does.
openjdk version "1.8.0_191" OpenJDK Runtime Environment (build 1.8.0_191-b12) OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
Here is the workaround: ... gzip -d tzdata2020b-rearguard.tar.gz touch pacificnew #empty file tar -rfv tzdata2020b-rearguard.tar pacificnew gzip -v tzdata2020b-rearguard.tar
Yes, that should work for 2020b. It shouldn't be needed for 2020c and later.
${JAVA_HOME_OPV}/bin/java -jar ${TZ_UPDATER_JAR} -u -f -l file:///${TZ_DATA_NFS} $JAVA_HOME_OPV/bin/java -jar ${TZ_UPDATER_JAR} -V|head -2|tail -1|awk -F":" '{print $2}'|awk -F"-" '{print $1}'
It returns expected result: tzdata2020b
This is a strong indication that the workaround should indeed work once 2020c comes out.
Hello Paul, I continue this topic started by Gerard, as when we apply the 2020c tzdb release we face a new issue that, again, makes the update impossible. Here is the error in log when we try an automatic update: : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. touch -md 2020-10-12T22:53:00Z \ tzdata2020c-rearguard.dir/pacificnew touch: invalid date format `2020-10-12T22:53:00Z' make[1]: *** [tzdata2020c-rearguard.tar.gz] Error 1 make[1]: Leaving directory `/tmp/tzdb-2020c' make: *** [rearguard_tarballs] Error 2 Thanks in advance for your feedback. Regards, Adrian-Ionut Lungu Orange Services - SSPO IMT/OINIS/NSSO/SSPO/CeR Mobile: +40 747447678 E-mail: adrian.lungu@orange.com -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Tuesday, October 13, 2020 8:45 PM To: MOISSET Gérard TGI/OLS <gerar.moisset@orange.com> Cc: LUNGU Adrian Ionut OSE <Adrian.Lungu@orange.com>; PEREIRA Mathieu TGI/OLS <mathieu.pereira@orange.com>; Time zone mailing list <tz@iana.org> Subject: Re: from tzdata2020a to tzdata2020b: iana, tzupdater, or local issue? On 10/13/20 2:07 AM, gerar.moisset@orange.com wrote:
I'd like to know why we are obliged to patch tzdata2020b-rearguard.tar.gz?
It's because TZUpdater uses tzdb internals that are not documented under "Interface stability" <https://data.iana.org/time-zones/theory.html#stability>, and when these internal details are changed, TZUpdater sometimes fails.
For us impact is it breaks automatic tz update. Does it mean we need to leave this kind of tz update?
As noted in <https://mm.icann.org/pipermail/tz/2020-October/029340.html> there will be a workaround in the next tzdb release, which should be reasonably soon, so one option is to wait until tzdb 2020c comes out and try its rearguard tarball. That being said, there's little coordination between the maintainers of tzdb and of TZUpdater, and as far as I know nobody has tested this specific workaround code. (You might be the first one to try it when 2020c comes out. :-)
Does it come from iana src content ? If not we are not obliged to reply, but I’d like to understand, does it come from tzupdater, or kind of jdk, or jdk version?
It's an incompatibility between tzdb (as published by IANA) and TZUpdater (maintained by Oracle).
tzupdater-2.2.0,
TZUpdater 2.3.1 is out, and you might want to update to it for other reasons. However, I expect that it has the same problem here that 2.2.0 does.
openjdk version "1.8.0_191" OpenJDK Runtime Environment (build 1.8.0_191-b12) OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
Here is the workaround: ... gzip -d tzdata2020b-rearguard.tar.gz touch pacificnew #empty file tar -rfv tzdata2020b-rearguard.tar pacificnew gzip -v tzdata2020b-rearguard.tar
Yes, that should work for 2020b. It shouldn't be needed for 2020c and later.
${JAVA_HOME_OPV}/bin/java -jar ${TZ_UPDATER_JAR} -u -f -l file:///${TZ_DATA_NFS} $JAVA_HOME_OPV/bin/java -jar ${TZ_UPDATER_JAR} -V|head -2|tail -1|awk -F":" '{print $2}'|awk -F"-" '{print $1}'
It returns expected result: tzdata2020b
This is a strong indication that the workaround should indeed work once 2020c comes out. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
On 10/19/20 11:31 PM, adrian.lungu@orange.com wrote:
touch -md 2020-10-12T22:53:00Z \ tzdata2020c-rearguard.dir/pacificnew touch: invalid date format `2020-10-12T22:53:00Z' make[1]: *** [tzdata2020c-rearguard.tar.gz] Error 1
This is most likely because your operating system has an old 'touch' that does not support POSIX-2008 or later. Please see the workaround mentioned here: https://mm.icann.org/pipermail/tz/2020-October/029356.html Or you can wait until 2020d comes out, which should be soon because of the Palestine change, and which should contain the workaround.
participants (2)
-
adrian.lungu＠orange.com -
Paul Eggert