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 \
 "