namest504 opened a new pull request, #76521: URL: https://github.com/apache/airflow/pull/76521
closes: #76520 With `start_from_trigger=True` on Airflow 3.3+, `DateTimeSensorAsync` puts the raw `target_time` into `start_trigger_args.trigger_kwargs`. Dag serialization encodes a datetime with `.timestamp()`, which reads a naive value in the process timezone instead of `core.default_timezone`. On a host running UTC with `default_timezone = Asia/Seoul` the sensor waits 9 hours too long; the other way round it fires 9 hours early. Before #73928 the operator stored the already localized `self._moment`, so this is a regression in 1.21.0. The fix stores `self._moment` when `target_time` is a datetime and keeps strings as they are, so Jinja templates are still rendered in the triggerer. The old `test_async_start_from_trigger_localizes_naive_datetime` only asserted that the naive value was passed through unchanged, which is the behaviour this PR removes, so it is replaced. The new test serializes the start trigger arguments, deserializes them, and checks the trigger's `moment` against the expected UTC instant under two process timezones and three kinds of `target_time`. The naive datetime cases fail before the change and pass after it. I also added a short note to the sensor docs about how naive datetimes are read. Tested with `pytest providers/standard/tests/unit/standard/sensors/test_date_time.py providers/standard/tests/unit/standard/triggers/test_temporal.py` (33 passed), and by running the Dag from the issue against 3.3.2: the naive task now succeeds right away like the other two. --- ##### Was generative AI tooling used to co-author this PR? - [ ] Yes (please specify the tool below) -- 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]
