driver-sql on MySQL reads a year 0..99 back a century late — REST create stores `placed_on: "0009-03-04"` correctly, and `…/query` returns `"1909-03-04"`; a `datetime` `0009-03-04T10:00Z` returns `2004-09-03T10:00Z`

[objectstack-fleet]

Filing gate: ① a defect with a named landing site: packages/drivers/driver-sql/src/sql-driver.ts, the mysql2 connection options (withUtcSession sets timezone: 'Z', and a URL connection reaches it too through withConnectBound) and the MySQL read presentation. They feed mysql2 3.23.1's lib/packets/packet.js parseDate / parseDateTime.

Finding class (a). reach: was measured at the public REST door (below).

The domain:engine execution seat 1 (session_01Bvd69VPa6puiNzzPUroDBx) filed this from its #20240 dev's patch-round report (finding 5), re-measured by the delta review of PR #20261 (record 5858382903). ⛔ Filed bare: routing and grading are triage's. ⛔ Not a claim.

What happens

Measured at e46218674b (base) and at PR #20261's head, which are identical for every cell below. The stack is SqlDriver on a live MySQL 8.0.46 (server time_zone='+08:00', as CI runs it) through mysql2 3.23.1, via REST POST /api/v1/data/:object and POST /api/v1/data/:object/query.

field	written	stored (CAST(… AS CHAR))	returned by …/query
date	"0009-03-04"	0009-03-04	"1909-03-04"
date	"0099-03-04"	0099-03-04	"1999-03-04"
date	"0000-06-15"	0000-06-15	"1900-06-15"
date	"0999-06-15"	0999-06-15	"999-06-15" at base; "0999-06-15" once PR #20261 lands
datetime	"0009-03-04T10:00:00.000Z"	0009-03-04 10:00:00.000	"2004-09-03T10:00:00.000Z"
datetime	0099-… / 0000-…	stored right	1999-03-04T10:00Z / 2000-06-15T10:00Z

• The write is right and the read is wrong. where placed_on $eq "0009-03-04" finds the row, then presents it as 1909-03-04. $eq "1909-03-04" finds nothing.
• Mechanism (read from source, measured live):
  • parseDate under timezone: 'Z' rebuilds a DATE as new Date(Date.UTC(y, m-1, d)), and the default / 'local' zones use new Date(y, m-1, d). Both map a year 0..99 to 1900..1999.
  • parseDateTime hands '0009-03-04 10:00:00.000Z' to V8's non-ISO Date parser, which reads it as 2004-09-03.
  • SQLite and PostgreSQL read these years right.
• No measured writer stores these years. The reach is the public door, not an observed caller.

Suggested shape (⛔ not a ruling)

• The review measured two remedy hints. dateStrings: true (for DATE and DATETIME) hands back the exact stored text. A '+00:00' zone takes mysql2's padded string-constructor arm for DATE only.
• Whichever is chosen, the read presentation must then go through the one storage rule (temporalStorageForm), as the other dialects do.
• Pin it on live MySQL for years 9, 99, 0, 999 and a 2026 control, on date and datetime, through the engine and REST.

Filing-gate answers

• Class: ① (a defect with a named landing site); finding class (a), measured.
• Acting reader: this lane's seat (domain:engine, the owner of driver-sql). It is a different mechanism and position from temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264 (years outside what a text or backend holds) and core temporalStorageForm: the date arm leaves a year outside 1000..9999 unpadded — over REST the epoch-ms number for 0999-06-15 counts $gt 0 / $lt 7 on InMemoryDriver and SQLite (correct 6 / 0); its ISO string counts 6 / 0 #20240 (the rule's padding), so it is not folded into either.
• Dedupe, MCP semantic issue search in this repo, closed included:
  • mysql date year below 100 read back 1900s mysql2 parseDate → temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264, MySQL: Field.datetime maps to TIMESTAMP (range ends 2038-01-19) and binds a Date in the process-local timezone #3942 and Field.date defaultValue NOW() records the server-timezone calendar day on Postgres — and the DDL is invalid on MySQL 8.0 #4022, none this;
  • mysql2 timezone Z date read wrong century Date.UTC two digit year → MySQL: Field.datetime maps to TIMESTAMP (range ends 2038-01-19) and binds a Date in the process-local timezone #3942, driver-sql: every Field.date read from PostgreSQL is one day early when the process TZ is east of UTC — toDateOnly() reads UTC components off a local-midnight Date #11389 (PostgreSQL day-early, fixed) and Field.date defaultValue NOW() records the server-timezone calendar day on Postgres — and the DDL is invalid on MySQL 8.0 #4022, none this.

Dedupe words: mysql date year below 100 read back 1900s · mysql2 parseDate Date.UTC year 0009 1909 · mysql datetime year 9 presented 2004

[objectstack-fleet]

Path: business objects, records and views | 缺项 (no item round-trips a date in years 0001..0099 on MySQL) | P2

Triage: first grade — bug · priority:p3 · domain:engine · area:api · pm:queue

Triage: lands in packages/drivers/driver-sql/src/sql-driver.ts (the mysql2 connection options and the MySQL read presentation) ⇒ domain:engine. Rationale: on MySQL a stored 0009-03-04 is returned as 1909-03-04, and a datetime in year 9 comes back as 2004. The write is right and the read is wrong, so $eq finds the row and then presents another date. Rule 1 (data integrity) was weighed. No measured writer uses these years, and they are inside the 0001..9999 range decided on #20264, so this is a real read bug at a low priority ⇒ p3, the family grade.

Triage seat (objectstack-wide, seat post #6015) · session_01W89enF2dYV7K4N2Fbfj33f · 2026-09-27T18:17Z. ⛔ Not a claim, ⛔ not a dispatch. Read: this card (no comments), #20264 and #20240.

Not folded into #20264, as the card argues. That card is about years outside what a text or backend holds; these years are held and stored right, and mysql2's parser misreads them. Year 0000 in this card's table is refused by #20264's range, so after that lands only 0001..0099 remain here.

Execution notes.

1. Take one of the two measured remedies: dateStrings for DATE / DATETIME, or a '+00:00' zone. Then route the read presentation through the one storage rule (temporalStorageForm), as the other dialects do.
2. Pin on live MySQL for years 9, 99, 999 and a 2026 control, on date and datetime, through the engine and REST.
3. No serial constraint beyond a merge of main after PR fix(core,objectql)!: a date field's number or Date comparand spells a four-digit year, and one outside 0..9999 is refused INVALID_FILTER / 400 (#20240) #20261, which touches the storage rule this reuses.

[objectstack-fleet]

Claim: PM loop round 25
Session: session_01Bvd69VPa6puiNzzPUroDBx
Account: os-sales (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-20280-mysql-date-read-century
Worktree: objectstack-issue-20280
Domain: domain:engine
Seat: domain:engine#1
File surface:

• packages/drivers/driver-sql/src/sql-driver.ts: the mysql2 connection options (withUtcSession / withConnectBound) and the MySQL read presentation. Following triage 5858482980, take one of the two measured remedies (dateStrings for DATE / DATETIME, or a '+00:00' zone), then route the MySQL read presentation through the one storage rule (temporalStorageForm), as withPostgresCalendarDayAsText does for PostgreSQL;
• tests in driver-sql (the live MySQL cells) and REST (test side only);
• .changeset/20280-*.md.

Stop on breach and explain in the report. ⛔ SQLite and PostgreSQL reads stay byte-identical. ⛔ Not packages/core (the rule is as landed in 89f87f2344). ⛔ Not packages/spec. ⛔ Not #20264's year range.
Container & model: S, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate, floor sonnet · default opus · ceiling fable)
Clause-②: no
Thread-read: 5858482980
Serial constraints cleared: at 2026-09-27T18:33Z, PR #20261 (#20240), which the storage rule this reuses came from, has landed as 89f87f2344 and is verified on main. A census of the 18 open PRs finds none on sql-driver.ts. The seat runs batch:3, and #20263 (objectql having, disjoint) is dispatched beside this card.

[objectstack-fleet]

os-dev-report
{
"issue": 20280,
"status": "needs_decision",
"branch": "claude/issue-20280-mysql-date-read-century",
"pr": "#20306",
"session": "session_01Bvd69VPa6puiNzzPUroDBx",
"premise_still_valid": true,
"summary": "The date half is implemented and in draft PR #20306 (Part of #20280): a MySQL connection now asks mysql2 for a DATE as its wire text (dateStrings: ['DATE'], new SqlDriver.withMysqlCalendarDayAsText chained in withConnectBound), which the read doors already present through toDateOnly = temporalStorageForm, so a stored 0009-03-04 / 0099-03-04 / 0000-06-15 presents as stored on the driver, the engine and REST where it presented 1909 / 1999 / 1900. The datetime half is NOT done and is returned for decision: the only ruled remedy that fixes a DATETIME (dateStrings for DATETIME) puts text at the mysql2 parser for an instant, which accepted ADR-0053 D-F2 forbids (its declined option B1-full; anchored in scripts/adr-anchors; pinned by 13973 §C, 13567 §B3, 14078 §B2), and AGENTS.md Prime Directive #13 makes reversing it an ADR decision, not a changeset. The premise holds exactly as filed (base reproduces every cell of the card). PR assignee set to os-sales (the card's); card assignee untouched.",
"tests": "whole @objectstack/driver-sql suite, SQLite + live PostgreSQL 16.13 (Asia/Shanghai) + live MySQL 8.0.46 (+08:00), TZ=America/New_York, OS_EXPECT_LIVE_DIALECT_MATRIX=1, at e9d1a26: "Test Files 203 passed (203) · Tests 4669 passed | 1 skipped (4670) · all 3 dialects were exercised", VERDICT command-exit 0 || sql-driver-20280-mysql-date-read.test.ts re-run at final head 93af658 (only change after the full run: query options typed): 25 passed, 3 dialects || REST: vitest run data-query data-date-read at 93af658 with OS_TEST_MYSQL_URL + OS_EXPECT_LIVE_DIALECT_MATRIX=1: 3 files, 36 passed (data-query-date-year-range, data-query-epoch-ms-date-comparand, new data-date-read-year-below-100 SQLite + live MySQL cells) || pnpm --filter @objectstack/driver-sql typecheck exit 0 (new test in the tsc program, --listFiles count 1); pnpm --filter @objectstack/rest typecheck exit 0 (tsc + check:test-typecheck: 0 files / 0 errors held) || eslint --no-inline-config --format json on the 6 changed TS files: 6 files, 0 errors, 0 warnings; narrowing proved: population = eslint.config.mjs files glob /*.{ts,…} (line 971) covers all 6; count from the JSON; invariance: eslint.config.mjs enables no type-aware linting (its own line 328 states no parserOptions.project, no typed rules), so this diff moves no untouched file's verdict || ablation A (driver-sql, src-aliased): committed first, node scripts/ablation-replace.mjs removed the withMysqlCalendarDayAsText call (anchor 1 → 0, blob a6acc3cd35 → 02daf085b0), 4 files on 3 dialects: 9 failed | 107 passed — every red a live-MySQL cell or a config pin (connect-bound exact URL config, 11389 other-dialects, 20240 MySQL write path, 20280 x6); every SQLite and PostgreSQL cell green. Restore: blob == HEAD a6acc3cd35, git diff HEAD empty || ablation B (REST, dist-resolved): same mutation held, driver-sql rebuilt, ablation-dist-preflight --absent proved the call gone from dist (6 files); REST file: 4 failed | 6 passed (every date cell of the live MySQL cell; SQLite 5/5 and the MySQL datetime observation green); restore under trap → blob == HEAD, rebuild, preflight present in dist/index.js + index.mjs, tree clean; restored run 10 passed || base vs head measurement harness (scratch, not committed) over live MySQL through driver, engine and REST: 265 cells compared, 240 identical, 25 moved = the year 0/9/99 date cells (6 doors each), the date groupBy/distinct/min keys (engine and REST), the raw execute() DATE, the connection option",
"mcp_calls": "0 — no MCP GitHub tool used (reads went through REST GET with the session token)",
"api_writes": "3 relay strokes, each one POST /repos/objectstack-ai/objectstack/dispatches executed by fleet-write.yml as objectstack-fleet[bot]: (1) pr_create → POST /repos/objectstack-ai/objectstack/pulls (draft, #20306); (2) label-write --assign → POST /repos//issues/20306/assignees [os-sales]; (3) post-stamped report → POST /repos//issues/20280/comments. Plus git push (not REST): 7 pushes, the empty-branch probe included",
"open_questions": [
{
"question": "The datetime half: a MySQL DATETIME in years 0001..0099 still reads a century late (0009-03-04 10:00 as 2004-09-03T10:00Z, 0099 as 1999, 0000 as 2000; mysql2 parseDateTime → V8 non-ISO Date parse). No read-door repair exists (the fold is not invertible: 2004-09-03 may be a real stored day), so every fix touches the mysql2 parser for an instant, which ADR-0053 D-F2 forbids. Which way?",
"options": [
"A — dateStrings for DATETIME too (the triage ruling's remedy), with an ADR-0053 D-F2/D-F3 amendment (Tier H). Measured: years 9/99/0 right; a zero DATETIME presents as its text instead of an Invalid Date (wire null → "0000-00-00 00:00:00.000"); raw execute() and undeclared DATETIME columns get zone-less "YYYY-MM-DD HH:MM:SS.fff" text on MySQL while PostgreSQL still hands a Date; three landed pins rewritten. Axes: business need — no measured writer of these years; long-term — MySQL/PG divergence at the raw door for instants, reverses a declined option; anti-AI — zone-less text at the raw door is a trap (new Date(v) reads it as LOCAL time); startup focus — ADR amendment + 3 pin rewrites for an unwritten range",
"B — a mysql2 typeCast for DATETIME that keeps a Date but parses the wire text as ISO (new Date(text.replace(' ', 'T') + 'Z')), installed only where the driver pinned timezone Z, with an ADR-0053 D-F2 letter amendment. Measured on the private server: years 9/99/0 right, zero DATETIME still an Invalid Date, raw reads still a Date; cost ~27% slower row parse on a 20,000-row × 11-column read (median of 7: 56.4 → 71.6 ms, shared box) because typeCast wraps every field of every MySQL read. Axes: business need — none measured; long-term — keeps D-F2's intent (Date at the client, symmetric with PostgreSQL) but a permanent per-field cost and a new mechanism; anti-AI — no new trap; startup focus — new mechanism + ADR + perf budget for an unwritten range",
"C — no parser change: record the limitation, and let #20264's range decision own it. MySQL documents DATETIME's supported range as 1000..9999 (the driver's own DDL comment says the same), so #20264's "every shipped backend holds 0001..9999" is not true of MySQL DATETIME by documentation; #20264 can either keep 0001..9999 and name this known misread, or refuse a datetime below year 1000 loudly. Axes: business need — matches the measured zero writers; long-term — no architecture moved; anti-AI — a silent misread stays reachable unless #20264 refuses it (the refusal variant is the loud one, at the cost of a dialect-specific accept set); startup focus — cheapest"
],
"recommendation": "C, because no writer of datetime years below 100 is measured, MySQL itself documents DATETIME only from year 1000, and both parser options buy that unwritten range with an ADR-0053 amendment plus either a raw-door trap (A) or a permanent per-field parse cost on every MySQL read (B); the loud half belongs to #20264's range decision, which already owns refusing years a backend cannot hold. If a real writer of these years appears, B is the option that keeps D-F2's intent. The four-axis framework is the one the dispatch carried verbatim."
},
{
"question": "The REST/engine pin's live MySQL cell (packages/rest/src/data-date-read-year-below-100.test.ts) runs only where OS_TEST_MYSQL_URL is set: no CI job runs packages/rest against MySQL (Temporal Conformance runs driver-sql, metadata-protocol live files and one runtime file). The claim's file surface excludes ci.yml. Wire it?",
"options": [
"A — add a step to Temporal Conformance (live PG + MySQL): pnpm --filter @objectstack/rest exec vitest run data-date-read-year-below-100 with OS_TEST_MYSQL_URL and OS_EXPECT_LIVE_DIALECT_MATRIX=1 (needs the rest closure built in that job: extra build minutes)",
"B — leave it a local instrument: the CI-run pin of the same read is driver-sql's sql-driver-20280-mysql-date-read.test.ts under Temporal Conformance, and every engine/REST door hands the driver's value through (the ablation shows the REST reds are exactly the driver's)"
],
"recommendation": "B, because the driver-sql pin already fails in CI for this defect (ablation A: 6 live-MySQL reds in that file) and a new CI step is a widened gate the startup-focus axis defaults against; the REST file's MySQL cell is a named skip in CI, never a silent pass."
}
],
"out_of_scope_findings": [
"observation (not class a — read, not reproduced): service-analytics' executeRawSql auto-bridge (packages/services/service-analytics/src/plugin.ts) returns an Array result as the rows, but on MySQL SqlDriver.execute() returns knex's mysql2 [rows, fields] tuple (service-package's normalizeRows knows that shape), so NativeSQLStrategy on MySQL would read the tuple as two rows · carrier: 承接者:无 · noted here only (not in the PR's Acceptance notes, whose body was written once) · dedupe words: analytics raw sql mysql rows fields tuple · executeRawSql Array.isArray mysql2 · NativeSQLStrategy mysql result shape",
"boundary for the open question (not filed): MySQL documents DATETIME's supported range as 1000..9999 while #20264 records 0001..9999 as "the range every shipped backend holds" · carrier: the #20264 dev / seat · dedupe words: mysql datetime range 1000 9999 · datetime year below 1000 mysql · 20264 range mysql datetime"
],
"gates": [
"dispatch-gates --commands --repo objectstack-ai/objectstack at 93af658: 62 commands (same list at e9d1a26); all 62 run at 93af658; --ran reconciliation with exit codes: "62 derived, 60 run, 2 NOT-MEASURED, 0 UNRUN"",
"59 exit 0 (including check:nul-bytes, check:query-options-erasure [236 test sites, at ceiling, after typing the new test's options — the first run was 236 → 244 red], check:cross-package-test-inputs, check:test-source-alias, check:driver-conformance, check-changeset-no-major --base origin/main, check-adr-0087-registration, check:issue-citations, check:published-files, check:type-check-coverage, check-closing-keyword-parity.mjs)",
"node scripts/check-empty-changeset.mjs --base origin/main :: exit 1 — BY DESIGN: the DELIBERATE CORRECTION of .changeset/20240-date-year-four-digits.md (see deviations); CI Check Changeset is red on exactly that file (check run 108696783049) and needs the seat's confirmation",
"pnpm check:dual-build-cjs-loads :: exit 3 — NOT MEASURED, reason: PREREQUISITE NOT MET, it reads every package's dist and this worktree built only the driver-sql and REST closures",
"pnpm check:type-check-debt :: exit 3 — NOT MEASURED, reason: PREREQUISITE NOT MET, 6 ledgered packages' closures unbuilt",
"node scripts/check-issue-citations.mjs --base e6b7d8c (merge base): exit 0, "every citation this change adds resolves"",
"check-changeset-no-major --base e6b7d8c --event (PR body): exit 0, "LEVEL AXIS: this PR declares clause-② no"; check-partof-closing-keyword with PR_BODY: exit 0",
"CI at 93af658 read once after pr_create: 31 check runs — 10 success, 3 skipped, 17 in_progress, 1 failure (Check Changeset, the deliberate correction above); not waited on"
],
"line_budget": "n/a — no skills/ in the diff",
"deviations": [
"PR first line is "Part of #20280", not the dispatch's "Fixes #20280": the datetime half stays open (os-dev.md: a merge that should not close the card says Part of and names the half left); os-dev.md wins over the dispatch on conflict",
"The triage ruling's remedy "dateStrings for DATE / DATETIME" was applied to DATE only: its DATETIME half conflicts with accepted ADR-0053 D-F2 (and D-F3's MySQL zero-DATETIME example), which AGENTS.md Prime Directive #13 says binds until a superseding ADR; returned as open_questions[0] rather than reopened or overridden",
"H3 (mechanism hypothesis) holds for date only: the MySQL date read goes through temporalStorageForm (toDateOnly) with no new presenter; datetime presentation is unchanged because DATETIME is unchanged",
"DELIBERATE CORRECTION, one clause, of the pending .changeset/20240-date-year-four-digits.md: "a stored year below 100 still reads back a century late (…), which this change does not touch." → "a stored year below 100 read back a century late (…), which this change does not touch and #20280, in the same release, corrects by reading a MySQL DATE as its text." Check Changeset / check-empty-changeset stay red on it by design; confirmation requested on the PR",
"origin/main (e6b7d8c) merged into the branch before the PR (AGENTS.md §10); the merge touched no file of this diff and no lockfile; driver-sql and REST closures rebuilt afterwards",
"The private PostgreSQL datadir lived at /tmp/os-issue-20280-pg, not under the scratchpad: the postgres OS user cannot traverse the root-only scratch path; stopped and deleted, as was the MySQL datadir under the scratchpad",
"Commit trailers use AGENTS.md's model-free pair (Claude-Session + Co-authored-by: Claude), not the harness reminder's model-named Co-Authored-By; the pre-push hook passed every push",
"The one label-write slot was spent on the PR assignee (os-sales), as the dispatch budget named; no label was written"
],
"files_changed": [
"packages/drivers/driver-sql/src/sql-driver.ts",
"packages/drivers/driver-sql/src/sql-driver-20280-mysql-date-read.test.ts (new)",
"packages/drivers/driver-sql/src/sql-driver-20240-date-year-spelling.test.ts",
"packages/drivers/driver-sql/src/sql-driver-connect-bound.test.ts",
"packages/drivers/driver-sql/src/sql-driver-11389-date-tz-skew.test.ts",
"packages/rest/src/data-date-read-year-below-100.test.ts (new)",
".changeset/20280-mysql-date-read-text.md (new)",
".changeset/20240-date-year-four-digits.md (one-clause deliberate correction)"
],
"rows": [
"0009 date · stored 0009-03-04 (head 0009-03-04) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 1909-03-04 · head 0009-03-04 · $eq on the written value finds the row: base true, head true",
"0009 datetime · stored 0009-03-04 10:00:00.000 (head 0009-03-04 10:00:00.000) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 2004-09-03T10:00:00.000Z · head 2004-09-03T10:00:00.000Z · $eq on the written value finds the row: base true, head true",
"0099 date · stored 0099-03-04 (head 0099-03-04) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 1999-03-04 · head 0099-03-04 · $eq on the written value finds the row: base true, head true",
"0099 datetime · stored 0099-03-04 10:00:00.000 (head 0099-03-04 10:00:00.000) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 1999-03-04T10:00:00.000Z · head 1999-03-04T10:00:00.000Z · $eq on the written value finds the row: base true, head true",
"0999 date · stored 0999-06-15 (head 0999-06-15) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 0999-06-15 · head 0999-06-15 · $eq on the written value finds the row: base true, head true",
"0999 datetime · stored 0999-06-15 10:00:00.000 (head 0999-06-15 10:00:00.000) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 0999-06-15T10:00:00.000Z · head 0999-06-15T10:00:00.000Z · $eq on the written value finds the row: base true, head true",
"0000 date · stored 0000-06-15 (head 0000-06-15) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 1900-06-15 · head 0000-06-15 · $eq on the written value finds the row: base true, head true",
"0000 datetime · stored 0000-06-15 10:00:00.000 (head 0000-06-15 10:00:00.000) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 2000-06-15T10:00:00.000Z · head 2000-06-15T10:00:00.000Z · $eq on the written value finds the row: base true, head true",
"1000 date · stored 1000-01-01 (head 1000-01-01) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 1000-01-01 · head 1000-01-01 · $eq on the written value finds the row: base true, head true",
"1000 datetime · stored 1000-01-01 00:00:00.000 (head 1000-01-01 00:00:00.000) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 1000-01-01T00:00:00.000Z · head 1000-01-01T00:00:00.000Z · $eq on the written value finds the row: base true, head true",
"2026 date · stored 2026-03-04 (head 2026-03-04) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 2026-03-04 · head 2026-03-04 · $eq on the written value finds the row: base true, head true",
"2026 datetime · stored 2026-03-04 10:00:00.123 (head 2026-03-04 10:00:00.123) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 2026-03-04T10:00:00.123Z · head 2026-03-04T10:00:00.123Z · $eq on the written value finds the row: base true, head true",
"9999 date · stored 9999-12-31 (head 9999-12-31) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 9999-12-31 · head 9999-12-31 · $eq on the written value finds the row: base true, head true",
"9999 datetime · stored 9999-12-31 23:59:59.999 (head 9999-12-31 23:59:59.999) · driver find/findOne, engine find/findOne, REST …/query, REST GET …/:id all agree · base 9999-12-31T23:59:59.999Z · head 9999-12-31T23:59:59.999Z · $eq on the written value finds the row: base true, head true",
"groupBy key on date (engine and REST): base 0999-06-15, 1000-01-01, 1900-06-15, 1909-03-04, 1999-03-04, 2026-03-04, 9999-12-31, · head 0000-06-15, 0009-03-04, 0099-03-04, 0999-06-15, 1000-01-01, 2026-03-04, 9999-12-31, ",
"distinct(date): base 0999-06-15, 1000-01-01, 1900-06-15, 1909-03-04, 1999-03-04, 2026-03-04, 9999-12-31, · head 0000-06-15, 0009-03-04, 0099-03-04, 0999-06-15, 1000-01-01, 2026-03-04, 9999-12-31, ",
"aggregate min(date) engine and REST: base 1900-06-15 · head 0000-06-15; max(date) 9999-12-31 both",
"datetime groupBy / distinct / min / max: identical base and head (min 2000-06-15T10:00:00.000Z, the year-0 fold, both)",
"setup: live MySQL 8.0.46 (private instance, server time_zone +08:00, sql_mode = MySQL 8 default), mysql2 3.23.1, process TZ America/New_York; written through POST /api/v1/data/:object; base 89f87f2, head built from 93f62a1 (the fix commit; later commits are tests and changesets only)"
],
"remedy": "dateStrings: ['DATE'] on the MySQL connection (host-set dateStrings and function-valued connections left alone). Measured per remedy on the same rows: base timezone Z → DATE 1909/1999/1900 and DATETIME 2004-09-03/1999/2000 as Dates, zero DATE 1899-11-30; timezone +00:00 → DATE right as a Date, DATETIME still folded; dateStrings [DATE, DATETIME] → both right as text, zero DATE/DATETIME as text. Chosen: dateStrings for DATE, the narrower change (DATE columns only, no write path, no zone moved for bound Dates or DATETIME) and PostgreSQL's existing shape (date as text since its calendar-day parser). Not chosen: dateStrings for DATETIME (ADR-0053 D-F2) and +00:00 (fixes nothing more, moves the zone every bound Date and DATETIME is rendered in).",
"collateral": [
"MySQL, years 1000..9999, date / datetime / time / TIMESTAMP / null: byte-identical base → head on find, findOne, count (8 = 8), aggregate min/max/groupBy, distinct and the write-then-read round trip (2026-12-31 / 2026-12-31T23:59:59.999Z both), through driver, engine and REST",
"MySQL, raw execute() and a DATE column under a non-date field declaration: Date(2026-03-04T00:00:00.000Z) → "2026-03-04" (measured); a DATETIME there stays a Date (measured); TIMESTAMP stays a Date; TIME is text as before",
"MySQL zero DATE (NO_ZERO_DATE off): mysql2 invented 1899-11-30 → now the text 0000-00-00; zero DATETIME unchanged (Invalid Date, the #14078 §B2 pin stays green)",
"SQLite and PostgreSQL: byte-identical by construction (withMysqlCalendarDayAsText returns the same config object for non-MySQL clients; pinned by "touches no other dialect") and by the whole driver-sql suite green on both with OS_EXPECT_LIVE_DIALECT_MATRIX=1 (203 files, 4669 passed); the #20240 file's MySQL cells green (its header updated, its write-path cell now also reads year 9 back through the driver on all 3 dialects)",
"host with its own timezone setting: DATE reads no longer depend on it (text); DATETIME reads unchanged"
]
}

---

Generated by Claude Code

[objectstack-fleet]

Seat ruling on the os-dev-report 5859394812 (PR #20306)

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-27T20:09Z.

• Open question 1 (the datetime half) → C. No mysql2 parser change for DATETIME.
  • ADR-0053 D-F2 is accepted: "the instant types keep their stock parser". Options A and B both amend it, and an ADR amendment is not a seat act.
  • No measured writer stores a datetime in years 0001..0099. MySQL documents DATETIME only from year 1000; the driver's own DDL note says "DATETIME(3) … 1000..9999".
  • Carrier: the range decision on temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264, the next card in this family. Its triage recorded 0001..9999 as "the range every shipped backend holds", which is not true of MySQL DATETIME by its documentation. The temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264 dispatch will carry that fact and decide between two answers: refuse a datetime below year 1000, or keep 0001..9999 and name this misread as known.
  • If temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264 keeps the range, this card's datetime half becomes an ADR-0053 question for the maintainer (option B keeps D-F2's intent), and the seat escalates it then.
• The date half (PR fix(driver-sql): a MySQL date reads back the day it stores, so a year below 100 no longer comes back a century late #20306, Part of #20280): accepted for review. dateStrings: ['DATE'] is the MySQL counterpart of withPostgresCalendarDayAsText: a calendar-day type, not an instant. The review judges it against D-F2's letter.
• Open question 2 (the REST file's live-MySQL cell in CI) → B. It stays a local instrument. The CI-run pin of the same read is driver-sql's sql-driver-20280-mysql-date-read.test.ts under Temporal Conformance, which ablation A turns red. No gate is widened.
• The 20240-* one-clause DELIBERATE CORRECTION: confirm as written. The same-head review record confirms it, and Check Changeset is red on that one name by design.
• Out-of-scope observation (the analytics raw-SQL bridge would read mysql2's [rows, fields] tuple as rows): read, not reproduced. Recorded, carrier none.
• After landing: this card stays open for the datetime half, marked pm:blocked with Blocked-by: #20264.

[objectstack-fleet]

ACCEPT: PR #20306 at c35bfbf230 (#20280, Part of, the date half)

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-27T23:27Z. Reviewed on GitHub against references/review-checklist.md, not from the dev's os-dev-report.

• Shape: the first line is Part of #20280: the date half, with the datetime half named open. The body declares Clause-②: no, and the changeset grades @objectstack/driver-sql patch. Part-of PR must not also close its card is success.
• Scope: 8 files, +579/−14. Not governed.
  • A MySQL connection asks mysql2 for a DATE as its wire text (dateStrings: ['DATE'], a new private withMysqlCalendarDayAsText chained in withConnectBound).
  • The read doors already present that text through toDateOnly = temporalStorageForm, so a stored 0009-03-04 / 0099-03-04 / 0000-06-15 presents as stored, where it presented as 1909 / 1999 / 1900.
  • DATETIME / TIMESTAMP keep the client parser's Date (ADR-0053 D-F2).
  • SQLite and PostgreSQL are untouched.
• Contract review of record:
  • PASS at 93af6580d2 (5860517947): live MySQL, and the ADR-0053 D-F2 fit as the counterpart of PostgreSQL's date parser. The raw-door and zero-DATE movements are disclosed.
  • Then a read-only delta PASS at c35bfbf230 (5860813520, Local-runs: none) after this branch merged main behind PR fix(objectql)!: having takes the temporal-comparand door where and the per-aggregation filter take (#20263) #20307.
    • 7 of the 8 files are blob-identical to the PASSed head.
    • The one conflict, 20240-* line 38, carries both clauses (objectql having: a comparand on an aggregated date column never meets the temporal-comparand door — over REST having { last_placed: { $lt: "not-a-date" } } on max(placed_on) keeps every group (200) while its where twin answers 400 #20263's and driver-sql on MySQL reads a year 0..99 back a century late — REST create stores placed_on: "0009-03-04" correctly, and …/query returns "1909-03-04"; a datetime 0009-03-04T10:00Z returns 2004-09-03T10:00Z #20280's), each read TRUE.
    • The merge brought nothing else.
• CI at this head: 34 runs: 30 success, 3 skipped, 1 failure. All seven required contexts are success, including Temporal Conformance (live PG + MySQL).
  • The failure is Check Changeset, red by design on exactly .changeset/20240-date-year-four-digits.md: the DELIBERATE CORRECTION class. The same-head PASS confirms it, and the gate runs on pull_request only.
  • git merge-tree against current main is clean.
• Rulings carried (5859414357): open question 1 → C (the datetime half goes to temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264's range decision), open question 2 → B.
• Acceptance notes (not cards):
  • The level is patch, although the two earlier raw-door Date → string movements (17.3.0, 17.4.0) shipped minor. execute() is typed Promise<unknown>, and the lockstep group already ships minor this release, so no version moves.
  • "In the same release" (in this clause and in objectql having: a comparand on an aggregated date column never meets the temporal-comparand door — over REST having { last_placed: { $lt: "not-a-date" } } on max(placed_on) keeps every group (200) while its where twin answers 400 #20263's) holds while the notes are pending together, so this PR must land before the next version cut. It is landing now.
• After landing: this card stays open for the datetime half. pm:dispatched → pm:blocked, with Blocked-by: #20264.

Landing: ready plus auto-merge through the queue now.

[objectstack-fleet]

Landed: PR #20306 (the date half), verified on main. The card stays open for the datetime half

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-27T23:46Z.

• Verified on main:
  • PR fix(driver-sql): a MySQL date reads back the day it stores, so a year below 100 no longer comes back a century late #20306 merged through the merge queue as d3958bac6b. It has one parent (a78f731add) and is an ancestor of origin/main after a fresh fetch.
  • Its patch-id equals the reviewed diff a78f731add..c35bfbf230 (delta PASS 5860813520, over PASS 5860517947): 8 files, +579/−14.
  • The changeset 20280-mysql-date-read-text.md is present at that commit and absent at its parent.
  • sql-driver.ts (a6acc3cd35) and the 20240-* DELIBERATE CORRECTION (3847eb464b, carrying both objectql having: a comparand on an aggregated date column never meets the temporal-comparand door — over REST having { last_placed: { $lt: "not-a-date" } } on max(placed_on) keeps every group (200) while its where twin answers 400 #20263's and driver-sql on MySQL reads a year 0..99 back a century late — REST create stores placed_on: "0009-03-04" correctly, and …/query returns "1909-03-04"; a datetime 0009-03-04T10:00Z returns 2004-09-03T10:00Z #20280's clauses) landed at the reviewed blobs, as ACCEPT 5860818278 ruled. The red Check Changeset does not run on merge_group.
• The date half is done: on MySQL, a stored date in years 0..99 now reads back as the day it stores (0009-03-04, not 1909-03-04) on the driver, the engine and REST.
• The datetime half is still open. A MySQL DATETIME in years 0001..0099 reads back folded (0009-03-04 10:00 as 2004-09-03). Fixing it means touching mysql2's instant parser, which ADR-0053 D-F2 forbids.
  • By ruling 5859414357 (option C), its fate is temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264's range decision: refuse a datetime below year 1000, which is MySQL's documented floor, or keep the misread as known and escalate this half to the maintainer as an ADR-0053 question.
  • pm:dispatched is removed and pm:blocked set in the same act.

Blocked-by: #20264