Uh oh!
There was an error while loading. Please reload this page.
docs(adr): ADR-0053 — date is a tz-naive calendar day, datetime is an instant (#1928) - #1962
Merged
Merged
Conversation
… instant (#1928) Proposes the industry-standard date/datetime split to root-fix the silent date-equality bug (#1874/#1928): a Field.date is stored as a full timestamp (write path doesn't normalize) while the filter path coerces query values to YYYY-MM-DD, so `date == daysFromNow(N)` never matches; and a UTC-midnight date renders off-by-one across timezones. Decision, staged by risk: - Phase 1 (low risk): Field.date is a YYYY-MM-DD string end-to-end (driver write/read normalization), aligning storage with the filter layer's existing date-only contract — fixes equality with no new semantics. - Phase 2 (needs review): reference-timezone model so today()/daysFromNow() and datetime rendering are tz-aware (wires up the unused sys-user-preference.timezone). Includes verified file:line evidence of the three-layer asymmetry, a mainstream-platform comparison (Salesforce/Postgres/java.time/Temporal/Airtable), migration/rollback, non-goals, and rejected alternatives. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Uh oh!
There was an error while loading. Please reload this page.
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 freeto 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.
Proposes the industry-standard
date/datetimesplit to root-fix the silent date-equality bug from #1874/#1928 (the one templates hit and we mitigated with day-window ranges + the #1950 lint).Problem (verified, file:line in the ADR)
Field.dateas a full timestamp (formatInputdoesn't normalize), but the filter path coerces query values toYYYY-MM-DD(coerceFilterValue). Sodate == daysFromNow(N)compares"2026-08-15T17:24Z"vs"2026-08-15"→ never matches. Ranges work only by lexicographic ISO accident.daysFromNow/daysAgokeep wall-clock time (unliketoday());today()is UTC, not user/org TZ — andsys-user-preference.timezoneexists but is never read.Decision (staged by risk)
Field.datebecomes aYYYY-MM-DDstring end-to-end via driver write/read normalization — aligns storage with the filter layer's already-existing date-only contract. Fixes equality with no new semantics; read-normalization repairs legacy rows with no migration.today()/daysFromNow()anddatetimerendering are timezone-aware.Includes a mainstream-platform comparison (Salesforce / Postgres / java.time / Temporal / Airtable — all converge on the same split), migration/rollback, non-goals, and rejected alternatives.
Docs-only; no code change in this PR.
🤖 Generated with Claude Code