python3-time-machine: fix ptest tzdata/dateutil issues

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>

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