Naive datetime values are interpreted in the host's local time zone

RustyPyType::try_into_value から始めて datetime の変換を確認し、続いて Python API リファレンス、クイックスタートガイド、チュートリアル、Context.add_variable の docstring の例を確認します。提案されている 3 つの naive datetime ポリシーを、既存の動作およびプロジェクトの方向性と比較します。ポリシーについて合意され、必要な場合は実装され、影響を受けるすべてのドキュメント例が一貫してそのポリシーを反映していれば完了です。

Behaviour

Converting a Python value to a CEL timestamp (in RustyPyType::try_into_value) handles a timezone-aware datetime correctly, but a naive one is passed through chrono::Local, so the same datetime(2026, 1, 1, 12) is a different instant on a UTC server and on a developer's laptop. CEL timestamps are absolute instants, and every timestamp(...) literal an expression builds is UTC, so comparisons like created > timestamp("2026-01-01T00:00:00Z") silently depend on TZ.

datetime.now() (naive) is the common way to hit this. The quick-start guide, the tutorials and the Context.add_variable docstring all use naive datetime.now() as the example value, so the docs currently teach the footgun.

Options

1. Keep local, document loudly. Matches Python's own convention (naive.timestamp() assumes local time). Least disruptive; add a warning box to the Python API reference and the datetime section of the tutorial, and switch the doc examples to datetime.now(timezone.utc).
2. Treat naive as UTC. Deterministic across machines and matches what most server code means. Silent behaviour change for anyone relying on option 1.
3. Reject naive datetimes with a ValueError that says to attach a tzinfo. Loudest and safest; a breaking change for existing callers.

My lean is 1 now (with the doc examples fixed) and 3 at the 1.0 boundary, since a policy engine that gives different answers per host TZ is the kind of bug that only shows up in production. Opinions welcome before anything changes.