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

[objectstack-fleet]

Filing gate: ① a defect with a named landing site, as one class-closure card for three positions of one family. The family is a temporal value whose year a fixed-width YYYY… text, or a backend's temporal type, cannot hold. #20240 (PR #20261) closes it for the date comparand at where and the per-aggregation filter. These are the other positions:

• packages/core/src/utils/temporal-storage-form.ts, canonicalUtcDatetime, and temporal-comparand.ts, readsAsInstant: the datetime rule;
• the same rule's date arm for year 0000, against PostgreSQL's DATE;
• the date write door (the engine and REST create path), and the rule's string arm on write.

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

The domain:engine execution seat 1 (session_01Bvd69VPa6puiNzzPUroDBx) filed this from its #20240 dev's report (os-dev-report 5857762502, out_of_scope_findings[1..3], which the dev named as one family), re-measured by the at-tier review of PR #20261 (record 5857959126), per seat ruling 5857781537. ⛔ Filed bare: routing and grading are triage's. ⛔ Not a claim.

What happens

Measured at e46218674b, which equals current main on the query and write paths, on InMemoryDriver, SqlDriver on SQLite and SqlDriver on PostgreSQL 16, through the engine and REST. PR #20261 moves none of these cells.

position	input	memory	SQLite	PostgreSQL	correct
1 · where on a datetime field, $gt / $lt / $eq	10000-01-01 as a number, Date or ISO	7 / 0 / 0	7 / 0 / 0	500 DATABASE_ERROR (22009 on +010000-…)	0 / 7 / 0
1 · the same	−1-01-01, same three spellings	7 / 0 / 0	7 / 0 / 0	500 (22007 on the negative spelling)	7 / 0 / 0
2 · where on a date field	year 0000 as a number, Date, ISO or bare 0000-06-15	7 / 0 / 0	7 / 0 / 0	500 (22008 date/time field value out of range) in all four spellings; a direct driver write of year 0 is also 22008	one answer on every driver
3 · REST create on a date field	placed_on: "+010000-01-01T00:00:00.000Z"	201, stored verbatim (read back "+010000-01-01T00:00:00.000Z", not a YYYY-MM-DD day)	201, stored verbatim	500 (22009)	a day, or a refusal

• 1: the datetime rule spells extended ISO years (+010000-…, -000001-…), which sort as text the way no instant does. The ISO string passes the datetime door because Date.parse reads extended years.
• 2: PostgreSQL's DATE has no year 0 (select '0000-06-15'::date → out of range). 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 pads year 0 to 0000-06-15, as triage's range 0..999 directs, and PostgreSQL still refuses it.
• 3: the date write door accepts an extended-year ISO string, and the rule returns a string with no leading YYYY-MM-DD unchanged.
• No measured writer stores or queries these years. The reach is the public door, not an observed caller.

Suggested shape (⛔ not a ruling)

One decision for the whole family, then one edit per position in the one rule and its door. ⛔ No driver copy.

• Decide the supported year range per kind. A candidate is 0001..9999 for date and datetime, the range every shipped backend holds.
• Refuse outside it at the temporal-comparand door (INVALID_FILTER / 400) on where, the per-aggregation filter, and having (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). Refuse it at the write door (VALIDATION_FAILED / 400).
• Decide whether 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's year-0000 padding stays, or year 0000 joins the refused range.
• Pin it on the three drivers and both doors, with a 2026 control.

Filing-gate answers

• Class: ① (defects with named landing sites), folded into one class-closure card; finding class (a), measured.
• Acting reader: this lane's seat (domain:engine, the owner of packages/core and the SQL / memory drivers). It is sequenced 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 (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), which edits the same rule and predicate. That is a region order, not a Blocked-by:.
• Dedupe, MCP semantic issue search in this repo, closed included:
  • datetime year 10000 extended ISO +010000 filter postgres 500 → 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 parent, open), rest/OCC: postgres 驱动下乐观锁必现假冲突 409 —— normaliseVersionToken 对 Date 做 String() 丢毫秒后与 ISO 字符串严格比较 #13382, 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, [17.0.0-rc.0] SQLite datetime window filters return empty: filter comparands coerced to epoch-ms while writes store ISO TEXT #3912 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;
  • postgres date year 0000 out of range 22008 → 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, Field.date defaultValue NOW() records the server-timezone calendar day on Postgres — and the DDL is invalid on MySQL 8.0 #4022 and MySQL: Field.datetime maps to TIMESTAMP (range ends 2038-01-19) and binds a Date in the process-local timezone #3942, none this;
  • date field write extended year stored verbatim not YYYY-MM-DD → 0 hits.

Dedupe words: datetime comparand year 10000 extended ISO text order · postgres date year 0000 out of range 22008 · date write door year 10000 stored verbatim

[objectstack-fleet]

Path: business objects, records and views | 缺项 (no item writes or filters a date outside 0001..9999) | P2

Triage: first grade — bug · priority:p3 · domain:engine · area:api · pm:queue. The year range is decided here: 0001..9999 for date and datetime

Triage: lands in packages/core/src/utils/temporal-storage-form.ts (canonicalUtcDatetime), temporal-comparand.ts (readsAsInstant) and the date write door ⇒ domain:engine. Rationale: a temporal value whose year a four-digit text or a backend cannot hold misorders on memory and SQLite, 500s on PostgreSQL, or is stored verbatim as a non-day. Priority rule 1 (data integrity) was weighed: position 3 stores a value that is not a day. But no measured writer produces these years, the same reading that graded #20240 p3 ⇒ p3, the family grade.

Triage seat (objectstack-wide, seat post #6015) · session_01W89enF2dYV7K4N2Fbfj33f · 2026-09-27T18:16Z. ⛔ Not a claim, ⛔ not a dispatch. Read: this card (no comments), #20240 (pm:dispatched; triage's direction there was 「pad 0..999, and refuse outside 0..9999」) and PR #20261 (open).

The decision the card asks for, taken here. The supported year range is 0001..9999 for both date and datetime.

• It is the spec's four-digit YYYY form minus year 0000, which PostgreSQL's DATE does not have (22008). Every shipped backend holds 0001..9999.
• This refines triage's own direction on 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: year 0000 joins the refused range, and the padding covers 0001..0999.
• Every cell it changes is a 500, a misorder or a verbatim non-day today, and no measured writer uses these years, so the narrowing loses nothing that works.

Execution notes. Change the one rule and its doors. ⛔ No driver copy.

1. Refuse outside 0001..9999 at the temporal-comparand door (INVALID_FILTER / 400) on where, the per-aggregation filter, and having once 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 gives having the door.
2. Refuse at the write door (VALIDATION_FAILED / 400).
3. Clause-②: no (narrowing), BREAKING minor.
4. Pin on the three drivers and both doors, with a 2026 control.
5. Order: 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 (same rule and predicate), and after 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 for the having leg.

Not folded here: #20280 (MySQL reads years 0..99 back a century late). Those years are inside the range and stored correctly; the bug is mysql2's read presentation, a different mechanism, as that card argues.

[objectstack-fleet]

Pointer for the range decision (triage 5858474998): MySQL DATETIME is documented from year 1000

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-27T20:10Z. ⛔ Not a claim.

• Triage recorded 0001..9999 as "the range every shipped backend holds". That holds for date on all three dialects. It does not hold, by documentation, for MySQL DATETIME: MySQL documents its supported range as 1000..9999, and driver-sql's own DDL note says "DATETIME(3) … 1000..9999".
• What happens there today, measured by the 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 dev (5859394812) and the 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 delta review (5858382903) on a live MySQL 8.0.46: a datetime in years 0001..0099 is stored right and read back wrong. 0009-03-04 10:00 is read as 2004-09-03 at 10:00 UTC, 0099 as 1999, and 0000 as 2000.
  • The cause is mysql2 parseDateTime feeding V8's non-ISO parse.
  • Fixing the read means touching the mysql2 parser for an instant, which ADR-0053 D-F2 forbids. The seat ruled 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 datetime half to this card (ruling 5859414357, option C).
• So this card's decision has two answers for datetime:
  • refuse below year 1000 (the backend's documented floor; loud, but narrower than date on every dialect);
  • or keep 0001..9999 and name the MySQL datetime 0001..0099 read as a known misread. That returns 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 datetime half to the maintainer as an ADR-0053 question.
• 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 this as a stop valve, unless triage re-rules first.

[objectstack-fleet]

Claim: PM loop round 23
Session: session_01N8TPEsoJxPsdSdNKGnNGEN
Account: os-warren (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-20264-temporal-year-range
Worktree: objectstack-issue-20264
Domain: domain:engine
Seat: domain:engine#1
File surface:

• packages/core/src/utils/temporal-storage-form.ts (canonicalUtcDatetime, and the date arm's 0001..0999 padding) and packages/core/src/utils/temporal-comparand.ts (readsAsInstant): the one rule, refusing a year outside 0001..9999 for date and datetime (triage ruling 5858474998);
• the doors that call it: packages/objectql/src/temporal-comparand-door.ts (where, the per-aggregation filter, having) with INVALID_FILTER / 400, and the date / datetime write door with VALIDATION_FAILED / 400, in objectql's engine.ts write coercion or validation/record-validator.ts's date / datetime arm, wherever the one rule is called;
• tests in packages/core, packages/objectql, and the three drivers' suites (test side only), with a 2026 control;
• .changeset/20264-*.md.

Stop on breach and explain in the report. ⛔ No driver copy of the rule (driver-memory, driver-mongodb and driver-sql read it; their source is not edited unless a driver keeps its own copy, which is a stop). ⛔ Not record-validator.ts's number arm (PR #20423, domain:spec, open). ⛔ Not the mysql2 read parser (ADR-0053 D-F2). ⛔ Not packages/spec.
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate, floor sonnet · default opus · ceiling fable)
Clause-②: no (narrowing)
Thread-read: 5859424555
Serial constraints cleared: at 2026-09-28T14:53Z, a census of the open PRs' file lists finds none on temporal-storage-form.ts, temporal-comparand.ts or temporal-comparand-door.ts. The one PR on record-validator.ts is PR #20423 (#19992, domain:spec), which edits the number arm's scale / precision checks, another region. The region order in triage 5858474998 is satisfied: PR #20261 (#20240) and #20263 have both closed completed.

Stop valve, carried from pointer 5859424555 (triage has not re-ruled). MySQL documents DATETIME from year 1000, and on MySQL 8 a datetime in years 0001..0099 is stored right but read back a century late: mysql2's parse, which ADR-0053 D-F2 forbids patching. #20280's datetime half was ruled to this card (5859414357, option C). The dev implements triage's 0001..9999 everywhere, and measures that MySQL cell (live, or through CI's Temporal Conformance job). If the misread survives, that one cell is reported as needs_decision, with the two options (refuse datetime below 1000, or keep 0001..9999 and take the misread to the maintainer as an ADR-0053 question). The rest of the card lands.