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

Brian Park 1884458 at bugs.launchpad.net
Sun Jun 21 21:18:50 UTC 2020


The stackoverflow question already has an answer for this. It's because
pytz does not accurately handle the constructor for `datetime` with
the`tzinfo` parameter. It will often give the wrong UTC offset. We need
to use the `timezone.localize()` method instead.

This little wart in the pytz API confuses people frequently. I have to
consult the pytz documentation every time I use it. The fact that it
confuses Paul Eggert makes me feel a little better.

I don't fully understand why pytz has this limitation, I think it has
something to do with the API exposed by the `datetime` class, and the
way pytz caches the DST transitions. This article by the author of
`dateutil` has a lot more info: https://blog.ganssle.io/articles/2018/03
/pytz-fastest-footgun.html. The newer `dateutil` package does not have
this problem.

By the way, both pytz and dateutil seems to have numerous inaccuracies
with regards to the DST offset for various timezones (I recall that the
negative -1:00 offset for Europe/Dublin is one of them). Both packages
currently support only 32-bit transitions, until year 2038. In addition,
dateutil has special problems for transitions in the year 2037, while
pytz handles those properly. I have not filed bugs against either
packages for the DST offset bugs: The pytz package seems to be in
maintenance mode. The large backlog of bugs on the `dateutil` package
indicates that the maintainer is too busy.

-- 
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



More information about the foundations-bugs mailing list