On 6/21/20 5:40 PM, Tom Lane wrote:
> * how quickly do you think that the "posixrules" file is likely
> to disappear in major distros, such as Debian, RHEL, macOS?
Probably NetBSD will go first as they tend to buy these changes quickly; maybe
six months from now? Debian and RHEL probably a couple of years. These are all
just guesses.
> * what exactly is the incompatibility with -b slim?
The problem occurs only when the -p option would make a difference, i.e., with
odd TZ settings like TZ='AST4ADT' that neither conform to POSIX (because they
specify DST but lack transition info) nor correspond to a TZif file. In this
case, the tzcode library mostly follows POSIX but fills in transition info from
the transitions in the posixrules file.
If the posixrules file was generated via '-b fat', this process fails for some
post-2037 timestamps in the tzcode implementation, and it fails for some current
timestamps in current glibc. Here's an example of a glibc failure for this
year's timestamps using tzdb (any tzdb version from 2005m through 2020a):
$ zdump -V -c2020,2021 AST4ADT
AST4ADT Sun Mar 8 07:59:59 2020 UT = Sun Mar 8 03:59:59 2020 AST isdst=0
gmtoff=-14400
AST4ADT Sun Mar 8 08:00:00 2020 UT = Sun Mar 8 05:00:00 2020 ADT isdst=1
gmtoff=-10800
AST4ADT Sun Nov 1 06:59:59 2020 UT = Sun Nov 1 03:59:59 2020 ADT isdst=1
gmtoff=-10800
AST4ADT Sun Nov 1 07:00:00 2020 UT = Sun Nov 1 03:00:00 2020 AST isdst=0
gmtoff=-14400
Those transitions are incorrect, since the spring-forward and fall-back times
should be 02:00, not 04:00.
If the posixrules file was generated via '-b slim', some of the necessary
posixrules information is absent (since this stuff is optional and it's not
needed except for the odd TZ settings), and so the posixrules calculations might
go awry in a different way. As it happens, with -b slim the above example works
correctly with glibc, but there are other cases where it fails in a different
way, using posixrules settings that pretty much nobody uses in practice (e.g.,
posixrules an alias for Europe/Paris and someone sets TZ='EET-2EEST'.)
Nobody should be using odd TZ settings like 'AST4ADT' or 'EET-2EEST' anyway
(because they don't work even with fat TZif files), so this stuff shouldn't
matter in real life.
