Pass native datetime and UUID literals to stub tasks

[jason810496]

• related: Support TaskFlow call syntax on stub tasks for the Lang SDK #69757 shipped the @task.stub TaskFlow arg-binding contract; this fills in the value half of it.
• next: Bind Python temporal and UUID arguments to their native Go types #71809

Why

A @task.stub TaskFlow call may only carry values json.dumps already knows, so the most natural arguments to pass a foreign-language task were rejected outright:

@task.stub(queue="golang")
def schedule_window(starts_at: datetime, every: timedelta, trace_id: UUID): ...


schedule_window(datetime(2024, 1, 2, 3, 4, 5), timedelta(minutes=5), UUID("6ba7b810-..."))

ValueError: @task.stub task 'schedule_window' parameter 'starts_at' received a literal of
type datetime that is not JSON-serializable, so it cannot be passed to the foreign runtime

The parameter's value_schema already told the runtime this was {"type": "string", "format": "date-time"} but the value could not travel.

What

Temporal and UUID literals are now rendered through the same Pydantic adapter that produced their value_schema, so the value and schema cannot disagree by construction. The conversion recurses through typed lists, sequences, tuples, mapping values, sets, and unions, so supported values use the same wire spelling at every depth. Sets containing supported leaves become deterministically sorted JSON arrays while uniqueItems: true tells the runtime it may reconstruct set semantics.

Python literal	Wire value after this PR	value_schema	Rejected before?	Rejected after?
datetime(2024, 1, 2, 3, 4, 5)	"2024-01-02T03:04:05Z"	{"type": "string", "format": "date-time"}	Yes	No
date(2024, 1, 2)	"2024-01-02"	{"type": "string", "format": "date"}	Yes	No
time(3, 4, 5)	"03:04:05"	{"type": "string", "format": "time"}	Yes	No
timedelta(days=1, hours=2)	"P1DT2H"	{"type": "string", "format": "duration"}	Yes	No
UUID("6BA7B810-...")	"6ba7b810-..."	{"type": "string", "format": "uuid"}	Yes	No
[datetime(2024, 1, 2, 3, 4, 5)]	["2024-01-02T03:04:05Z"]	{"type": "array", "items": {"type": "string", "format": "date-time"}}	Yes	No
{datetime(2024, 1, 2), datetime(2024, 1, 3)}	["2024-01-02T00:00:00Z", "2024-01-03T00:00:00Z"]	{"type": "array", "items": {"type": "string", "format": "date-time"}, "uniqueItems": true}	Yes	No
Status.READY for plain Enum	rejected, no wire value	{"type": "string", "enum": ["ready"], "title": "Status"}	Yes	Yes
Status.READY for str-backed Enum	"ready"	{"type": "string", "enum": ["ready"], "title": "Status"}	No	No
Priority.HIGH for int-backed Enum	1	{"type": "integer", "enum": [1], "title": "Priority"}	No	No
Decimal("1.20")	rejected, no wire value	number or numeric string	Yes	Yes
Path("/tmp/example")	rejected, no wire value	{"type": "string", "format": "path"}	Yes	Yes

Only temporal and UUID leaves opt into Pydantic serialization. Plain Enum members, Decimal, and Path retain their previous rejection behavior; string- and integer-backed Enums retain their existing JSON-native behavior, and bytes remain unsupported. Schema generation and literal conversion are deliberately separate: Pydantic may describe a type even when its Python object cannot be emitted as JSON.

Timezone-naive timestamps

A naive datetime is pinned to an explicit offset before serializing, via the same coerce_datetime the rest of Airflow uses. An offset-less timestamp is a different instant to each language runtime, so leaving it naive would make a task's behaviour depend on which language happens to run it.

Wire value	Go	Java Instant.parse	JS new Date
2024-01-02T03:04:05Z	03:04:05Z	03:04:05Z	03:04:05Z
2024-01-02T03:04:05	03:04:05Z	throws	08:04:05Z (worker-local)

---

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

• Yes, with help of Claude Code following the guidelines

[jason810496]

Thanks TP for the review.