aaron-y-chen opened a new pull request, #76112: URL: https://github.com/apache/airflow/pull/76112
The scheduled build on `main` started failing in every job that runs the non-DB core tests (Non-DB and lowest-dependency core tests on Python 3.11-3.14, plus the Latest Boto and Pendulum2 special tests): https://github.com/apache/airflow/actions/runs/41157855924 ``` FAILED airflow-core/tests/unit/timetables/test_cron_mixin.py::test_get_next_across_dst[havana-next-target-in-gap] got DateTime(2027, 3, 14, 4, 0, tzinfo=UTC), expected DateTime(2027, 3, 14, 5, 0, tzinfo=UTC) FAILED airflow-core/tests/unit/timetables/test_cron_mixin.py::test_localize_all_folds[havana-fold] got [2026-11-01 04:00 UTC], expected [2026-11-01 04:00 UTC, 2026-11-01 05:00 UTC] ``` ### Why [tzdata 2026f](https://github.com/eggert/tz/blob/main/NEWS) (released 2026-10-27) records that Cuba will not fall back to -05 on 2026-11-01 and stays on -04 until 2027-11-07. The `America/Havana` cases added in #75847 were built on that upcoming fall-back and on the following spring-forward, so with the new data 2026-11-01 00:00 is no longer a fold and 2027-03-14 00:00 is no longer a gap. The CI image picked up the new data from Debian: in the CI image build of the failing run, `tzdata 2026f-0+deb13u1` replaced `2026e-0+deb13u1`. `zoneinfo` reads the system tz database, so environments that still have 2026e or older keep passing. That is why the scheduled runs after #75847 was merged stayed green until this one. Only two cases fail, but six other Havana cases dated 2026-11-01 are affected too. They still pass under 2026f because the instants they expect still exist, but 2026-11-01 00:00 no longer occurs twice, so they no longer exercise the fold they describe. ### Change Move all `America/Havana` cases to the 2025 transitions (spring-forward 2025-03-09, fall-back 2025-11-02): - Havana stays the test zone. Its transitions happen at local midnight, which is what puts the Sunday-only and day-of-month crons of these cases into the fold or the gap. Zones that change at 01:00 or 02:00 would need different crons and expectations. - Past transitions are not changed by future rule updates, so the cases give the same result on tzdata before and after 2026f. Using the next future Havana transition would leave the tests exposed to the next short-notice change. - The sparse cron moves from day 1 to day 2 of March/November because the 2025 fall-back is on November 2. March 2 is still before the March 9 spring-forward, so both ends of the span stay at -05:00, as the case comments say. - `havana-prev-gap-at-one-hour` (2026-03-08) was not affected. It moves to 2025 so that all Havana cases use the same DST year. Test-only change, so no newsfragment. ### Testing Ran `uv run --project airflow-core pytest airflow-core/tests/unit/timetables/test_cron_mixin.py` with `PYTHONTZPATH` pointing to the IANA 2026e and 2026f releases compiled with `zic`: | | tzdata 2026e | tzdata 2026f | |---|---|---| | `main` | 33 passed | 2 failed (the two CI failures), 31 passed | | this PR | 33 passed | 33 passed | On both tzdata versions I also checked that the new target wall times still hit the DST edge in `America/Havana`: 2025-11-02 00:00 and 00:30 each resolve to two instants (-04:00 and -05:00), and 2025-03-09 00:00 resolves to none. related: #75847 --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes (please specify the tool below) Generated-by: Claude Code (Opus 5.5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
