Naive datetime values are interpreted in the host's local time zone
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
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.
Written by the indexing model from the issue text.
Description
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 todatetime.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
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.
- Dominant language
- Python
- Stars
- 43
- Forks
- 4
- Avg merge
- 9h 57m
- Merged PRs (30d)
- 14
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hardbyte/python-common-expression-language
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in hardbyte/python-common-expression-language
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
canonical/paas-charm#368 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
tech debt
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
StevenBlack/hosts#3256 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
qualcomm/qai-appbuilder#275 ·