Tl;DR:
Upstream timezone-data-2020b changed the way /usr/share/zoneinfo
files are generated by default. Gentoo does NOT enable this new
default to keep existing software running (so far).
You can enable new default explicitly with USE=zic-slim switch.
Libraries and tools that parse /usr/share/zoneinfo will break in trivial
(crashes) or very obscure ways (DST time switch will not happen and
will report wrong time).
What can you do:
If you are feeling brave then enable USE=zic-slim to identify and
fix affected packages. Sometimes bugs are specific to a timezone
you are in. Running a testsuite is probably the best way to find
problems.
If you found a bug check that USE=-zic-slim makes it go away and
report (and/or fix) it upstream and add it to the gentoo's tracker
bug:
https://bugs.gentoo.org/749591.
What actually changed:
From https://data.iana.org/time-zones/tzdb/NEWS:
```
Release 2020b - 2020-10-06 18:35:04 -0700
...
zic now defaults to '-b slim' instead of to '-b fat'.
```
Mechanically both 'fat' and 'slim' are the same VER=2 (or 3 for some
timezones) file format from 'man 5 tzfile'. But 'fat'/'slim' contents
is different. From 'man 8 zic':
```
-b bloat
If bloat is fat, generate additional data entries that work
around potential bugs or incompatibilities in older software,
such as software that mishandles the 64-bit generated data.
If bloat is slim, keep the output files small; this can help check
for the bugs and incompatibilities.
Although the default is currently fat, this is intended to
change in future zic versions, as software that mishandles the
64-bit data typically mishandles timestamps after the year 2038
anyway.
```
Thus ideally libraries should already handle both flavours. But due
to bugs some libraries will break.
File format spec is an RFC8536:
https://www.rfc-editor.org/rfc/rfc8536.txt
Good luck!
--
Sergei
