diff mbox series

[meta-python,14/16] python3-time-machine: fix ptest tzdata/dateutil issues

Message ID 20260829001108.559544-14-khem.raj@oss.qualcomm.com
State New
Headers show
Series [meta-python,01/16] python3-bleak: fetch git tag with tests/ for ptest instead of PyPI sdist | expand

Commit Message

Khem Raj Aug. 29, 2026, 12:11 a.m. UTC 
From: Khem Raj <raj.khem@gmail.com>

time_machine's C-level time/timezone patching relies on libc's
tzset()//usr/share/zoneinfo, which requires the system tzdata package -
distinct from python3-tzdata (Python's importlib zoneinfo data), which
the recipe already had. Add tzdata to RDEPENDS:${PN}-ptest.

Deselect test_destination_datetime_tzinfo_non_zoneinfo:  it builds an
aware datetime from dateutil's tz.gettz("America/Chicago") and expects
the CST (-6h) offset at the 1970 epoch. OE builds /usr/share/zoneinfo
in "slim" format (zic -b slim); dateutil's tzfile parser mishandles
the pre-first-transition instant of a slim tzfile and returns a 0
(UTC) offset there, so the epoch maps to 0 instead of 21600. Python's
own zoneinfo reads the same file correctly, so this is a
dateutil/slim-tzdata limitation, not a time_machine bug.

AI-Generated: Uses Claude Code
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../python/python3-time-machine_3.2.0.bb              | 11 +++++++++++
 1 file changed, 11 insertions(+)
diff mbox series

Patch

diff --git a/meta-python/recipes-devtools/python/python3-time-machine_3.2.0.bb b/meta-python/recipes-devtools/python/python3-time-machine_3.2.0.bb
index 8e2fa51bb4..32d64f8d14 100644
--- a/meta-python/recipes-devtools/python/python3-time-machine_3.2.0.bb
+++ b/meta-python/recipes-devtools/python/python3-time-machine_3.2.0.bb
@@ -19,10 +19,21 @@  RDEPENDS:${PN} += "\
 do_install_ptest:append() {
     install -d ${D}${PTEST_PATH}/tests
     cp -rf ${S}/tests/* ${D}${PTEST_PATH}/tests/
+    # test_destination_datetime_tzinfo_non_zoneinfo builds an aware datetime
+    # from dateutil's tz.gettz("America/Chicago") and expects the CST (-6h)
+    # offset at the 1970 epoch. OE builds /usr/share/zoneinfo in "slim" format
+    # (zic -b slim); dateutil's tzfile parser mishandles the pre-first-transition
+    # instant of a slim tzfile and returns a 0 (UTC) offset, so the epoch maps to
+    # 0 instead of 21600. Python's own zoneinfo reads the same file correctly, so
+    # this is a dateutil/slim-tzdata limitation, not a time_machine bug.
+    sed -i -e "/--automake/ s|\$| --deselect tests/test_time_machine.py::test_destination_datetime_tzinfo_non_zoneinfo|" \
+        ${D}${PTEST_PATH}/run-ptest
 }
 
 RDEPENDS:${PN}-ptest += "\
     python3-dateutil \
+    python3-dateutil-zoneinfo \
     python3-freezegun \
     python3-tokenize-rt \
+    tzdata \
 "