Dates use the writer's local date with no timezone, so teammates stamp different days

Class: unstated · Severity: cosmetic Flow: arch-3e305bc76ff0 · Step: date stamping Question: None · Frequency: n/a

Finding¶

created, updated and verified use the writer's local date with no timezone recorded, and staleness is computed in whole local days.

What happens today¶

SystemClock.today() returns date.today() — local.

Impact¶

Two teammates in different timezones can stamp different dates for the same moment; staleness can differ by a day. Immaterial at a 365-day cadence.

Proposed default¶

Accept as-is; record the choice so it is not rediscovered as a bug.

Resolution¶

FIXED 2026-07-29 properly, at the maintainer's direction: SystemClock.today() returns the UTC calendar date rather than the local one. No migration mechanism — the project has no users yet, so existing dates are not worth a compatibility path. The original entry proposed accepting the skew as immaterial at a 365-day cadence, which was true of the staleness consequence and missed the other one: these dates are written into committed files and read by other people, so two teammates either side of midnight stamped different dates for the same moment. That is a correctness problem in shared data, not a rounding problem in a heuristic. Pinned by a test asserting against a UTC date computed in the test rather than against date.today(), which is the local value the fix moved away from.

Actors affected¶

• repository maintainer

Evidence¶

• src/docir/platform/clock/system.py

---

Migrated from the discovery gap register (GAP-038); the register itself now lives in this store.