hardbyte / hardbyte/python-common-expression-language
Naive datetime values are interpreted in the host's local time zone
- Lenguaje dominante
- Python
- Estrellas
- 43
- Forks
- 4
- Merge medio
- 9 h 57 min
- PR fusionados (30 d)
- 14
Descripción
## 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.
Guía de contribución
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python, rust
- Área
- api, backend
- Tipo de issue
- Error
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Activo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 35/100