#1084120 python3-dateutil: [y2038 issue] only reads 32-bit (version 0) zoneinfo files

#1084120#5
Date:
2024-10-05 08:34:51 UTC
From:
To:
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

#1084120#10
Date:
2024-10-05 11:33:58 UTC
From:
To:
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.

#1084120#23
Date:
2024-10-05 12:04:53 UTC
From:
To:
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

#1084120#36
Date:
2024-10-05 12:12:45 UTC
From:
To:
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

#1084120#45
Date:
2024-10-05 17:47:27 UTC
From:
To:
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.