[tz] from tzdata2020a to tzdata2020b: iana, tzupdater, or local issue?

[adrian.lungu at orange.com]

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 at orange.com



-----Original Message-----
From: Paul Eggert <eggert at cs.ucla.edu> 
Sent: Tuesday, October 13, 2020 8:45 PM
To: MOISSET Gérard TGI/OLS <gerar.moisset at orange.com>
Cc: LUNGU Adrian Ionut OSE <Adrian.Lungu at orange.com>; PEREIRA Mathieu TGI/OLS <mathieu.pereira at orange.com>; Time zone mailing list <tz at iana.org>
Subject: Re: from tzdata2020a to tzdata2020b: iana, tzupdater, or local issue?

On 10/13/20 2:07 AM, gerar.moisset at 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.