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

Abierto

#50 abierto el 14/9/2026 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad: 5/5
Tiempo estimado: Más de una semana
Aptitud para principiantes: 35/100

Tipo de issue: Error
Claridad: Bastante claro
Estado de actividad: Activo
Stack tecnológico: python, rust
Área: api, backend

Línea de trabajo

Empieza en RustyPyType::try_into_value e inspecciona la conversión de datetime; después, revisa la referencia de la API de Python, la guía de inicio rápido, los tutoriales y los ejemplos de la docstring de Context.add_variable. Compara las tres políticas propuestas para los valores de fecha y hora naive con el comportamiento existente y la dirección del proyecto. Se considera terminado cuando la política se haya acordado, se haya implementado si es necesario y todos los ejemplos de documentación afectados la reflejen de forma coherente.

Escrito por el modelo de indexación a partir del texto del issue.

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

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.

Lenguaje dominante: Python
Estrellas: 43
Forks: 4
Merge medio: 9 h 57 min
PR fusionados (30 d): 14