- Package:
- python3-dateutil
- Source:
- python3-dateutil
- Submitter:
- Jochen Sprickerhof
- Date:
- 2024-10-05 18:06:01 UTC
- Severity:
- normal
Hi,
starting with 2024b-1 the timezone offset in /etc/localtime is always
zero:
$ mmdebstrap --variant=essential --include=python3-dateutil --essential-hook='echo tzdata tzdata/Areas select Europe | chroot "$1" debconf-set-selections' --essential-hook='echo tzdata tzdata/Zones/Europe select Berlin | chroot "$1" debconf-set-selections' --chrooted-customize-hook='python3 -c \'from dateutil import tz; from datetime import datetime; print(datetime.strptime("2024-2-3T12:13", "%Y-%m-%dT%H:%M").replace(tzinfo=tz.gettz()).utcoffset())\'' unstable /dev/null
[...]
0:00:00
But if you replace unstable with testing in the above call to get
version 2024a-4 it returns:
1:00:00
I also tested with other zones like Australia/Adelaide (should be
10:30:00).
Cheers Jochen
It looks like this is specific to Python dateutil, not to /etc/localtime: dateutil.tz.gettz now always returns UTC, even if given a timezone name. https://salsa.debian.org/science-team/pandas/-/jobs/6379871 Upstream python3-dateutil aren't *obviously* aware of this, but their CI is failing and I haven't checked exactly why.
Control: clone -1 -2 Control: reassign -1 tzdata Control: reassign -2 python3-dateutil Control: severity -2 important Control: forwarded -2 https://github.com/dateutil/dateutil/issues/1059 I have just uploaded a new tzdata to fix this issue, switching back from the 'fat' format. I am therefore cloning the bug instead. python3-dateutil is aware of this issue for many time, but there hasn't been any recent activity: https://github.com/dateutil/dateutil/issues/1059 This needs to be fixed anyway by 2038 to avoid any breakage by that date. Regards Aurelien
Control: forwarded -1 https://github.com/dateutil/dateutil/issues/462 Control: retitle -1 python3-dateutil: [y2038 issue] only reads 32-bit (version 0) zoneinfo files Actually this is a better upstream issue, and the problem is known for 7+ years: https://github.com/dateutil/dateutil/issues/462 Regards Aurelien
Upstream have two potential fixes, but both are several years old and not merged: https://github.com/dateutil/dateutil/pull/1091 https://github.com/dateutil/dateutil/pull/1130 I haven't tried either of them.