hardbyte / hardbyte/python-common-expression-language
Naive datetime values are interpreted in the host's local time zone
- Vorherrschende Sprache
- Python
- Sterne
- 43
- Forks
- 4
- Ø Merge
- 9 Std. 57 Min.
- Gemergte PRs (30 T.)
- 14
Beschreibung
## 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.
Beitragsleitfaden
Rechercherichtung
Start at RustyPyType::try_into_value and inspect the datetime conversion, then review the Python API reference, quick-start guide, tutorials, and Context.add_variable docstring examples. Compare the three proposed naive-datetime policies with existing behavior and project direction. Done means the policy is agreed, implemented if required, and all affected documentation examples consistently reflect it.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- python, rust
- Bereich
- api, backend
- Issue-Typ
- Bug
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Aktiv
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100