fix: normalise sqlite timestamps to UTC in timeToString (RUK-139) - #23
Merged
Conversation
SQLite stores timestamps as RFC3339 text and compares them
lexicographically. A row written in a non-UTC zone
("2026-05-25T16:00:00+03:00") compares wrong against a UTC row
("2026-05-25T13:00:00Z") even though both moments are identical —
'Z' > '+' in ASCII, so the offset row sorts before the UTC row of
the same instant. Healer/cleaner WHERE clauses then either miss
stuck tasks or pick them up at the wrong moment.
Force UTC at the write boundary (timeToString) and the order is
stable for every row this package writes. All storage WHERE clauses
already go through timeToString for their comparison values, so the
fix is one .UTC() call.
Acceptance for RUK-139 was originally "store INTEGER unix-ms". We
do NOT do that here: SQLite is positioned as dev/test only in the
README, the timestamp column rewrite would be a breaking schema
change + jet regen + bind rewrite (~50 lines + new go.mod tooling),
and the UTC normalisation closes the practical risk surface (all
goque-side writes are now consistent; only external writers
hand-inserting non-UTC rows are still at risk and that's out of
scope for a goque-managed table).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
1 participant
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.
SQLite stores timestamps as RFC3339 text and compares them
lexicographically. A row written in a non-UTC zone
("2026-05-25T16:00:00+03:00") compares wrong against a UTC row
("2026-05-25T13:00:00Z") even though both moments are identical —
'Z' > '+' in ASCII, so the offset row sorts before the UTC row of
the same instant. Healer/cleaner WHERE clauses then either miss
stuck tasks or pick them up at the wrong moment.
Force UTC at the write boundary (timeToString) and the order is
stable for every row this package writes. All storage WHERE clauses
already go through timeToString for their comparison values, so the
fix is one .UTC() call.
Acceptance for RUK-139 was originally "store INTEGER unix-ms". We
do NOT do that here: SQLite is positioned as dev/test only in the
README, the timestamp column rewrite would be a breaking schema
change + jet regen + bind rewrite (~50 lines + new go.mod tooling),
and the UTC normalisation closes the practical risk surface (all
goque-side writes are now consistent; only external writers
hand-inserting non-UTC rows are still at risk and that's out of
scope for a goque-managed table).
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com