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