Recording the sweep #13567 deliberately declined to answer, so it does not close with that card. Filed by the seat that implemented #13567's option 1, per the triage note on that card: the question currently exists only as a paragraph of prose inside another issue's body, where it is invisible to candidate queries and staleness alerts.
The question
updated_at is not the only value whose RUNTIME TYPE differs between the drivers that materialise a JS Date (Postgres, MySQL, MongoDB) and the ones that hand back ISO text (the SQLite family, memory). The OCC seam was a production bug precisely because a consumer compared such a value with String(v) on both sides while every test it had drove the text side.
So: which other consumers compare, sort, key or format one of these values, while only ever being exercised against the text-side drivers?
Why this is worth a card and not a paragraph
The class is the expensive one AGENTS.md already names — a green suite that is not a suite, on exactly the path a double was introduced for. It is invisible to the type system: on the Date drivers the value is a Date, on the text drivers it is a string, and both flow through the same any-shaped record. A consumer that happens to be correct for one is not thereby correct for the other, and nothing today reports which consumers are in that position.
The two facts that make it findable are now pinned rather than assumed, in packages/drivers/driver-sql/src/sql-driver-13567-audit-stamp-materialisation.test.ts: the live dialects hand updated_at out of the record read door as a Date, and SQLite hands it out as canonical ISO-8601-Z text.
Executable criteria for whoever picks this up
This is a SWEEP — a census with a verdict per site — not a fix. Done means:
- Enumerate the values. Every field or builtin column whose materialised JS type is driver-dependent, derived rather than recalled: the audit columns (
created_at, updated_at), Field.datetime, and anything else the drivers do not normalise on read. SqlDriver#formatOutput is the authority for driver-sql — note which of its repairs sit inside if (this.isSqlite) and which run for every dialect, because that gating IS the divergence. - Enumerate the consumers. Every site that does
String(v), v1 === v2, .localeCompare, template interpolation, .startsWith, a sort comparator, a Map key, or a date format on one of those values, across packages/** — with the search expression recorded so the census can be re-run. - Give each site a verdict: (a) correct on both shapes; (b) correct only because the value happens to arrive as text in every test it has; (c) genuinely wrong on one side. Class (b) is the finding — it is the state the OCC seam was in.
- Report which consumers are tested against a
Date-materialising driver at all. A consumer that has never seen one is class (b) by construction. - Class (c) sites become their own cards. Class (b) sites become a decision: pin the composed fact where a live server exists, normalise at the producer, or record the acceptance.
Explicitly NOT part of this
Backlinks
Recorded from #13567 (the OCC coverage gap) and the repair that preceded it, #13382. Neither is addressed by this card, and this card does not close either.
Generated by Claude Code
Recording the sweep #13567 deliberately declined to answer, so it does not close with that card. Filed by the seat that implemented #13567's option 1, per the triage note on that card: the question currently exists only as a paragraph of prose inside another issue's body, where it is invisible to candidate queries and staleness alerts.
The question
updated_atis not the only value whose RUNTIME TYPE differs between the drivers that materialise a JSDate(Postgres, MySQL, MongoDB) and the ones that hand back ISO text (the SQLite family, memory). The OCC seam was a production bug precisely because a consumer compared such a value withString(v)on both sides while every test it had drove the text side.So: which other consumers compare, sort, key or format one of these values, while only ever being exercised against the text-side drivers?
Why this is worth a card and not a paragraph
The class is the expensive one AGENTS.md already names — a green suite that is not a suite, on exactly the path a double was introduced for. It is invisible to the type system: on the
Datedrivers the value is aDate, on the text drivers it is astring, and both flow through the sameany-shaped record. A consumer that happens to be correct for one is not thereby correct for the other, and nothing today reports which consumers are in that position.The two facts that make it findable are now pinned rather than assumed, in
packages/drivers/driver-sql/src/sql-driver-13567-audit-stamp-materialisation.test.ts: the live dialects handupdated_atout of the record read door as aDate, and SQLite hands it out as canonical ISO-8601-Z text.Executable criteria for whoever picks this up
This is a SWEEP — a census with a verdict per site — not a fix. Done means:
created_at,updated_at),Field.datetime, and anything else the drivers do not normalise on read.SqlDriver#formatOutputis the authority for driver-sql — note which of its repairs sit insideif (this.isSqlite)and which run for every dialect, because that gating IS the divergence.String(v),v1 === v2,.localeCompare, template interpolation,.startsWith, a sort comparator, aMapkey, or a date format on one of those values, acrosspackages/**— with the search expression recorded so the census can be re-run.Date-materialising driver at all. A consumer that has never seen one is class (b) by construction.Explicitly NOT part of this
withPostgresCalendarDayAsTextstates it deliberately: "timestamptz/timestampare deliberately untouched: those are instants, aDateis the right materialisation for them."??fallback at any consumer. Where a consumer is wrong, the contract question is which side owes the canonical spelling.Backlinks
Recorded from #13567 (the OCC coverage gap) and the repair that preceded it, #13382. Neither is addressed by this card, and this card does not close either.
Generated by Claude Code