Fix TimeSensor dag_version churn via TimeOfDayTrigger

[Vamsi-klu]

What is the change?

TimeSensor(start_from_trigger=True) now starts through a new TimeOfDayTrigger that stores only the parse-stable target_time and tz and resolves the concrete UTC moment when the trigger starts. TimeSensor.__init__ builds a per-instance StartTriggerArgs instead of mutating the class attribute.

Why did I do it?

Two defects. __init__ mutated the shared class-level StartTriggerArgs, so every sensor advertised the last-constructed sensor's moment. And that moment came from datetime.now() at parse time, so each Dag-processor parse produced a different serialized blob and a new DagVersion.

Fixes: #69543

How did I do it?

I added TimeOfDayTrigger plus resolve_time_of_day_moment and serializable_timezone helpers in triggers/temporal.py. Spring-forward gaps shift forward, ambiguous fall-back times use fold=0, and serialize() persists the resolved moment so a reconstruct after midnight does not move the wait target. execute() and poke() resolve the moment once per attempt and cache it. A sensor with no Dag falls back to UTC when poking and raises for start_from_trigger.

What's the impact?

No more dag_version churn from repeated parses. The start_from_trigger API is preserved, so no major bump of apache-airflow-providers-standard. trigger_kwargs stays accepted and ignored.

What's the test plan?

pytest providers/standard/tests/unit/standard/sensors/test_time.py -q and pytest providers/standard/tests/unit/standard/triggers/test_temporal.py -q. New tests cover serialization stability across mocked now(), midnight caching, DST spring and fall, fixed and named timezones, shared-class isolation, and end_from_trigger propagation.

[potiuk]

Thanks — the underlying diagnosis is right and worth fixing: baking target_datetime into start_trigger_args at parse time means the serialized Dag hash changes every day, and the hash-stability test you added is a good way to pin that.

But the fix is to remove start-from-trigger support from TimeSensor, and that's a bigger call than the PR framing suggests. Anyone using TimeSensor(start_from_trigger=True) today has their sensor start directly in the Triggerer; after this it warns, is ignored, and the task instead occupies a worker slot to poke or defer. That's a functional regression for those users, not just churn cleanup.

Concretely that needs: a major version bump on apache-airflow-providers-standard (currently 1.16.0) and an entry under the Changelog header in providers/standard/docs/changelog.rst spelling out the required user action. Neither is in the diff. (No newsfragment — providers don't use those.)

The design question I'd like your view on: was removal the only option? Computing moment lazily — so start_trigger_args serializes a stable placeholder and the concrete datetime is resolved when the trigger actually starts — would fix the hash churn while keeping the feature. If that was tried and doesn't work, saying why in the description would help; if it wasn't, it seems worth a look before dropping a documented capability.

One correction to something I'd have flagged: trigger_kwargs is already accepted-and-ignored on main (it's declared in __init__ but never read), so dropping it here changes nothing. Not an issue with this PR.

---

To be clear about where this stands: the points above are mostly design questions rather than defects, and I'd rather you formed your own view on them than took mine as settled. My review here was AI-assisted, and I'd guess parts of this PR were too — that's fine on both sides, but it means neither of us should treat the output as authoritative. Please push back where you think the reasoning is wrong, and say what you think the right trade-off is between fixing the hash churn and keeping the feature.

I'd also like other maintainers to weigh in before this is decided. Removing a documented capability from a released provider isn't a call I want to make on my own, and folks closer to the start-from-trigger design will have better context here than I do.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

[uranusjr]

This and #69925 fix the same thing in different ways. We should first figure out the correct approach in the issue.

I see there is another discussion relaated to how to solve it . I dismiss my review to unblock it.

[uranusjr]

Although we could import the timezone encode/decode logic from SDK, I think it’s probably not be worst idea to have them directly inside the provider code. The important thing here is both sides must agree, and having them both in the same place is more important for the provider than reducing duplication from Airflow Core or SDK.

Only one minor suggestion on using replace instead of the class directly.