Arch Linux

Probably related to https://gitlab.gnome.org/GNOME/glib/-/issues/2219 ?

If not, it could very well be in i3pystatus, which is not supported.

Confirmed with GNOME.

The problem appears to be that python-pytz (in [community]) that i3pystatus uses cannot read the tzdata correctly any more after the tzdata 2020b update:

from pytz import timezone
from datetime import datetime
berlin = timezone('Europe/Berlin')
print(berlin.utcoffset(datetime(2020,10,1)))

should print "2:00:00" with tzdata 2020a, but prints "0:00:00" after the update to tzdata 2020b. This affects e.g. the "clock" module in py3status and probably everything else using python-pytz as well.

Other software using time zone information appears to be unaffected, e.g. the "date" command.

This should be fixed with 2020b-2 for now. Please test.

I confirm that after the update to tzdata 2020b-2, python-pytz can parse the tzfiles as expected again. Thank you for the quick update, I signed off the package in [testing] :)

Now that glib2 has been fixed can we try again with slim bloat or are more time zone reading tools broken?

python-pytz has its own tzfile parser (https://github.com/stub42/pytz/blob/master/src/pytz/tzfile.py) that does not appear to be compatible with "zic -b slim", so removing the workaround from tzdata will break this package.

For python-pytz we patch it to use system tzdata insteasd of its own internal database. We might drop that for now and open an upstream request to support new default zic -b slim, Jelle?

I submitted a bug report for python-pytz upstream: https://github.com/stub42/pytz/issues/48

python-dateutil fails tests too: https://github.com/dateutil/dateutil/issues/1059

python-pytz should be fixed with the new release building its own fat timezone datafiles
https://github.com/stub42/pytz/commit/d6a6878c0a4637d859f488bf4a76d51092d8cb36

Pytz has always built its own timezones data, but we devendor this in order to make sure the user always has the most up to date information from the canonical system version (and because vendoring isn't our favorite experience).

Now that python 3.9 has the stdlib zoneinfo module (available all the way back to 3.6 via backports.zoneinfo) which does support slim files, hopefully pytz will stop being used and projects will migrate to the stdlib.

There is currently discussion about the possibility that pytz might wrap its own API around backports.zoneinfo to gain support for slim files and transparently support the system timezone files even. That would be the ideal scenario.

I suggest we close this one because we've reverted for now to fat tzdata database and have it working again as before.

For the future please someone who's following may open a new report to undo that revert once we have python-pytz working with python 3.9 timezone reading or start some todo list
to keep pushing various projects if more are affected.