[iceboundrock]

Why

test_temporal_standalone_takes_no_receiver compared today() with date.today(). today() lowers to DataFusion's current_date(), which uses the session time zone. ltseq sets none, so it returns the UTC date. date.today() returns the local date. Wherever the process's zone is not UTC, the test failed for part of every day. Under TZ=UTC it could also fail if UTC midnight passed between the query and the Python call. CI runs in UTC, so only local runs hit this, but it cost the #225 acceptance review a manual investigation.

Change

The test now reads the UTC date just before and just after the query. It asserts that every row holds the same date and that this date is one of those two readings. This keeps the check pinned to today's behaviour (today() is the UTC date), because a local-date result still fails whenever the two dates differ. The rollover race is gone because one of the two readings always matches. Production code is unchanged. Whether today() should instead follow a local or configurable zone is a separate product question; if that changes, this test changes with it.

Setting TZ=UTC in CI alone was not done: CI already runs in UTC, so it would leave local runs failing and the midnight race in place.

Validation

Run at 21:09 UTC on 2026-11-08:

• pytest py-ltseq/tests/test_standalone_calls.py passed (13 of 13) under TZ=UTC, TZ=Etc/GMT-14, TZ=Etc/GMT+12 and TZ=America/New_York.
• The test as it stands on main, run at the same moment, failed under TZ=Etc/GMT-14 (local date already Nov 9) and passed under TZ=Etc/GMT+12. That confirms the original failure and that the new assertion still tells the UTC date from a local one.

The midnight rollover case was not run; it rests on the before/after logic. The full suite was left to CI.

Not covered

test_new_functions.py::test_age_recent builds date.today().replace(year=...+1), which raises on Feb 29, and dt.age() uses the same UTC current_date(). The issue lists it as related but separate, so it is left alone here.

Closes #249

[iceboundrock]

AI Code Review — Round 1

Reviewed HEAD: 66271f49e54140cfd38e2a97612ec9c9f8d2ea63 against base main (merge base 6240a936255a5fa314df0c6b6c71a5fe3bb740c1)

Findings

None.

Spec

Satisfies issue #249: explicit UTC readings bracket query evaluation, accommodating midnight rollover while retaining checks for exactly four identical dates. Changes are confined to the intended test and its datetime import; production behavior is unchanged.

Standards

Consistent with AGENTS.md, CLAUDE.md and repository conventions. The explanatory comment documents the UTC assumption and rollover rationale. No production behavior change requires changelog, docstring or stub updates.

Assessment

Correct, narrowly scoped test-reliability fix. No correctness, security or coverage defects found.

Observations

The supplied PR snapshot confirms the bound HEAD and base main. All four CI checks were pending in that snapshot; their eventual outcomes are unknown.

Verification

Read the issue, PR description, checks, repository guidance, full bound diff and related expression/session code. Ran test_standalone_calls.py under TZ=UTC, TZ=Etc/GMT-14, TZ=Etc/GMT+12 and TZ=America/New_York: 13 passed per zone, 52 total. In-memory clock substitutions exercised both sides of a simulated UTC rollover bracket with real today() queries; both passed. Additional in-memory substitutions confirmed rejection of wrong dates, mixed dates, missing rows and empty results. These simulations did not change the system clock or repository files. git diff --check passed; HEAD remained bound and the final worktree was clean.

Summary

No findings and no further fix round needed. Focused tests passed in all required time zones, and simulated rollover checks support the midnight-race fix. Full CI results remain pending in the supplied snapshot.

Needs another fix round: NO