[Bug 1884458] Re: pytz mishandles Africa/Khartoum in 2017

[Paul Eggert]

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


** Bug watch added: github.com/dateutil/dateutil/issues #1059
   https://github.com/dateutil/dateutil/issues/1059

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to python-tz in Ubuntu.
https://bugs.launchpad.net/bugs/1884458

Title:
  pytz mishandles Africa/Khartoum in 2017

Status in python-tz package in Ubuntu:
  New

Bug description:
  Here's a scenario illustrating the bug, on Fedora 31:

  $ python3
  Python 3.7.7 (default, Mar 13 2020, 10:23:39) 
  [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import datetime
  >>> import pytz
  >>> print(datetime.datetime(2017,10,31, tzinfo=pytz.timezone('Africa/Khartoum')))
  2017-10-31 00:00:00+02:10

  That "+02:10" is incorrect, as Khartoum was 3 hours ahead of UTC, not
  2 hours and 10 minutes ahead of UTC. GNU 'date' gets it right:

  $ TZ=Africa/Khartoum date -d'2017-10-31' +'%Y-%m-%d %H:%M:%S %z'
  2017-10-31 00:00:00 +0300

  For more, see:

  https://stackoverflow.com/questions/62501007/pytz-giving-wrong-
  timezone-offset-for-africa-khartoum

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-tz/+bug/1884458/+subscriptions