Comment 3 for bug 1884458

Part of the problem is that when pytz/tzfile.py reads a TZif file, its build_tzinfo function parses only the file's version-1 data, which is limited to 32-bit timestamps that stop working after 2038. In 1995 the TZif file format was expanded to include 64-bit transition times and a POSIX-style TZ string for future timestamps, and tzfile.py needs to support that. Without that support, tzfile.py's build_tzinfo function mishandles some timestamps after 2038 on most platforms. Worse, build_tzinfo mishandles current timestamps on NetBSD 9.0 because NetBSD 9.0 uses the new 'zic -b slim' option that causes TZif files to omit 32-bit data deducible from the 64-bit data that code written since 1995 is supposed to be looking at instead.

For more on this topic, please see the dateutil bug report here:

https://github.com/dateutil/dateutil/issues/1059

which dateutil's maintainer indicates is a bug that is reasonably high on his radar.

I suggest that the priority of this pytz bug be increased, as pytz is already broken for current timestamps on NetBSD 9.0 and this problem will start occurring on other distros as "zic -b slim" becomes more popular - see:

https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3