| 2020-07-06 07:34:39 |
Stuart Bishop |
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 |
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. |
|
