Fix DateTimeSensor crash when target_time renders to a datetime

[1fanwang]

target_time is a template field, so it is only rendered after __init__ runs. DateTimeSensor validated and normalized it in the constructor — acting on the un-rendered Jinja expression — and poke() parsed self.target_time directly with timezone.parse(). When target_time is templated and the Dag uses render_template_as_native_obj=True, the field renders to a datetime, and poke() crashed:

TypeError: argument 'input': 'DateTime' object cannot be cast as 'str'

The deferrable path already read the value through _moment, which handles both str and datetime, so only the synchronous sensor was affected. The constructor now stores target_time verbatim, and the datetime→ISO-string normalization it used to do is relocated into _moment rather than dropped; self.target_time itself is never mutated. _moment still parses and validates the rendered value, and both sensors route through it. __init__ only assigns the template field now, in line with the burn-down in #70296.

related: #70296

Testing Done

Operator-level repro (real Dag, real render, real poke) — before the fix:

target_time after render: DateTime(2020, 1, 1, 0, 0, 0, tzinfo=Timezone('UTC')) DateTime
Traceback (most recent call last):
...
return timezone.utcnow() > timezone.parse(self.target_time)
TypeError: argument 'input': 'DateTime' object cannot be cast as 'str'

After the fix:

target_time after render: DateTime(2020, 1, 1, 0, 0, 0, tzinfo=Timezone('UTC')) DateTime
poke -> True

test_date_time.py: 13 passed. The two normalization guards — _moment resolves a native-rendered and a constructor-passed datetime to an aware datetime — fail on the pre-fix source and pass after.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: GitHub Copilot CLI following the guidelines

Concerns addressed

[shahar1]

Almost there,
Also - please ensure enough test coverage for all edge cases, thanks!

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker 3c99701 v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.