Repository navigation
fix(witan-core): write timestamps at millisecond precision - #462
Merged
Merged
Conversation
now_iso() emitted six fractional digits. omnigraph 0.12 and later refuse a
DateTime with non-zero digits past the third ("a DateTime has millisecond
precision; fractional-second digits past the third must be zero"), so every
write that stamps a time would fail after the 0.13 pin bump.
0.11 already truncates to milliseconds on write and both versions return
millisecond values on read, so stored data and the paths that re-send a
stored timestamp are unaffected.
Claude-Session: https://claude.ai/code/session_01Mfmuz4DTn557AV8V17o98A
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused change preserves UTC formatting, includes regression coverage, and has no identified blocking issues.
0 open findings
What changed in this PR
Updates witan-core’s shared timestamp helper for omnigraph 0.12+ compatibility while preserving UTC formatting.
Changes:
- Emits timestamps with exactly three fractional digits.
- Adds regression coverage for millisecond precision.
- Records the compatibility fix in a changelog fragment.
| File | Description |
|---|---|
| packages/witan-core/witan_core/timeutil.py | Uses millisecond precision and documents why. |
| packages/witan-core/tests/test_timeutil.py | Checks for three fractional digits. |
| packages/witan-core/changelog.d/20261008_131307_blarghmatey_omnigraph_013_datetime_millis.md | Documents the timestamp compatibility fix. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This was referenced Oct 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What are the relevant tickets?
N/A (witan task tk-write-datetime-values-at-millisecond-precision-0-9018b6, part of the omnigraph 0.13 upgrade, spec in #461 D7)
Description (What does it do?)
now_iso()returneddatetime.now(UTC).isoformat(), which carries six fractional digits. omnigraph 0.12 and later refuse aDateTimewith non-zero digits past the third, so every witan write that stamps a time would fail after the pin bump.This makes
now_iso()emittimespec="milliseconds". It is the only place witan generates a timestamp that reaches the graph (council'sserver.py, witan-code'sindexer.pyandbridge.pyall go through it).The paths that read a stored timestamp and send it back (
created_aton re-keyed rows,closed_at/claimed_at/first_claimed_atmerged in_update_task,store_mergeloads of exported rows) are unchanged. 0.11 truncates to milliseconds on write, and both 0.11 and 0.13 return millisecond values on read, so nothing stored carries more than three digits.Safe on 0.11, so it can merge ahead of the pin. The pin bump should also raise both servers'
witan-core>=floors to the release carrying this: an older witan-core still imports fine, socheck-core-floorwill not catch it.How can this be tested?
just test-witan-core713 passed,just test-witan-council1429 passed,just test-witan-code682 passed.2026-10-08T17:00:00.123456+00:00and reads it back as2026-10-08T17:00:00.123. 0.13.0 refuses that value (invalid DateTime literal ... fractional-second digits past the third must be zero), accepts.123+00:00, and reads it back as.123.https://claude.ai/code/session_01Mfmuz4DTn557AV8V17o98A