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
- 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).
- Treat naive as UTC. Deterministic across machines and matches what most server code means. Silent behaviour change for anyone relying on option 1.
- 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.
Behaviour
Converting a Python value to a CEL
timestamp(inRustyPyType::try_into_value) handles a timezone-awaredatetimecorrectly, but a naive one is passed throughchrono::Local, so the samedatetime(2026, 1, 1, 12)is a different instant on aUTCserver and on a developer's laptop. CEL timestamps are absolute instants, and everytimestamp(...)literal an expression builds is UTC, so comparisons likecreated > timestamp("2026-01-01T00:00:00Z")silently depend onTZ.datetime.now()(naive) is the common way to hit this. The quick-start guide, the tutorials and theContext.add_variabledocstring all use naivedatetime.now()as the example value, so the docs currently teach the footgun.Options
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 todatetime.now(timezone.utc).ValueErrorthat says to attach atzinfo. 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.