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

Paul Eggert eggert at cs.ucla.edu
Tue Oct 13 17:44:39 UTC 2020

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.

More information about the tz mailing list