(I hope for pytz to become a compatibility layer for old code, wrapping
the Python 3.9 zoneinfo code and allowing codebases to transition
seamlessly)
** Package changed: python-tz (Ubuntu) => pytz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
The (awful) API provided by pytz and the requirement for localize() is
there for legacy reasons. At the time, it was the only way to get the
Python datetime library to do what was needed to get cross-timezone, DST
aware arithmetic working. The future is the new built-in support in
Python 3.9, avail
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 s
** Changed in: python-tz (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1884458
Title:
pytz mishandles Africa/Khartoum in 2017
To manage notifications about
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 conf
I should have written that I see the same bug symptoms on Ubuntu
18.04.4.
** Also affects: python-tz (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: pytz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
