Bulk import reads a naive datetime cell in the process-local timezone, so an export/edit/re-import round trip shifts the instant

[os-zhuang]

Found while implementing #8373 (export renders datetime cells in the business timezone); filed rather than fixed there — it is the import side of the same seam and outside that card's declared surface.

What

parseDateCell() in packages/rest/src/import-coerce.ts ends with:

const parsed = new Date(s);
if (Number.isNaN(parsed.getTime())) return undefined;
...
return parsed.toISOString();

A cell like 2026-08-01 06:00:00 carries no offset, so new Date(s) interprets it in the process timezone (ECMAScript: a date-time form with no offset is local time; date-only forms are UTC — which is why the YYYY-MM-DD fast path above it is fine). The import path therefore stores a different instant depending on the deployment host's TZ, and never consults the caller's business timezone, which resolveExecCtx has already resolved on this route.

Measured:

TZ=Asia/Shanghai node -e "console.log(new Date('2026-08-01 06:00:00').toISOString())"
# 2026-07-31T22:00:00.000Z
TZ=UTC node -e "console.log(new Date('2026-08-01 06:00:00').toISOString())"
# 2026-08-01T06:00:00.000Z

Same file, same tenant, same cell — eight hours apart, decided by a host setting nobody authoring the spreadsheet can see.

Why it matters

Export and import are advertised as inverses (import-coerce.ts opens with "This is the inverse of export-format.ts"), and the export writes a naive YYYY-MM-DD HH:mm:ss cell with no offset. So the natural workflow — export, edit in a spreadsheet, re-import — is only lossless when the host TZ happens to equal the clock the export wrote in:

• Before 【缺陷】数据导出(CSV/XLSX)日期时间列硬编码按 UTC 渲染,与界面时区不一致(@objectstack/rest export-format.ts formatDate) #8373 the export wrote UTC wall time; a host at TZ=Asia/Shanghai re-imported it as +08 and shifted every datetime by 8 hours.
• After 【缺陷】数据导出(CSV/XLSX)日期时间列硬编码按 UTC 渲染,与界面时区不一致(@objectstack/rest export-format.ts formatDate) #8373 the export writes business-tz wall time; the round trip is now correct exactly when TZ equals the business timezone (the reported deployment's case) and wrong by the difference otherwise.

Either way the correctness of the round trip rests on a host env var rather than on the tenant's configured timezone. The defect predates #8373; #8373 changes which deployments happen to be lucky.

Suggested direction

Read the cell in the business timezone: thread ExecutionContext.timezone into the import coercion and, for a naive datetime, interpret the wall clock in that zone. zonedDateStartToUtcMs in packages/core/src/utils/datetime.ts already does the wall-clock-to-instant direction DST-safely (Intl.DateTimeFormat offsets, never hand-rolled arithmetic) and is the natural primitive to generalise from date-only to date-time. Fall back to the current behaviour when no timezone is resolved.

Worth deciding explicitly as part of the fix: whether a cell that does carry an offset (2026-08-01T06:00:00+08:00, or a trailing Z) keeps being honoured as written — it should, and the change should only affect naive cells.

Scope

• packages/rest/src/import-coerce.ts — parseDateCell and its coerceValue caller
• the import route's call sites in packages/rest/src/rest-server.ts / import-prepare.ts
• tests in packages/rest (a cross-day case, not a mid-day one — this shifts rows across month boundaries the same way 【缺陷】数据导出(CSV/XLSX)日期时间列硬编码按 UTC 渲染,与界面时区不一致(@objectstack/rest export-format.ts formatDate) #8373 did)

Related: #8373.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/rest (import-coerce.ts + import route call sites) ⇒ domain:cli. Queued as Bug: export and import are advertised as inverses, and the naive-datetime read is decided by the host TZ rather than the tenant's resolved business timezone — measured 8-hour shift on a round trip. The suggested primitive (zonedDateStartToUtcMs) and the offset-carrying-cell carve-out are in the body. Sibling of #8484 (filename half, same seam, same lane) — small enough to batch if the seat confirms disjoint-or-serial file handling, since both touch packages/rest.

Size/model suggestion: M.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 8
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8485-import-naive-datetime-business-tz
Worktree: objectstack-issue-8485
Domain: domain:cli
File surface: packages/rest/src/import-coerce.ts, packages/rest/src/import-prepare.ts, packages/core/src/utils/datetime.ts, tests in both packages (stop on breach and explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: #8484 (the export half of this same seam) merged as PR #8720 before this claim. No in-flight card declares packages/rest/src/import-*.

Re-priced against the merged export half rather than dispatched as written. This card was filed before #8484 landed and its "Suggested direction" describes the pre-#8484 tree. Two facts measured on origin/main at claim time change the shape of the work:

• zonedWallClock now exists at packages/rest/src/export-format.ts:262, but it is module-private and runs the instant → wall clock direction. It is not the primitive this card needs and cannot be imported as-is.
• zonedDateStartToUtcMs (packages/core/src/utils/datetime.ts:75, exported) runs the direction this card does need — wall clock → instant, DST-safe via Intl offsets — but only for date-only input. Generalising it to date-time is the actual job, as the card guessed.

One inconsistency the dev has to resolve rather than inherit: the two primitives disagree on the no-zone-resolves case. zonedDateStartToUtcMs falls back to UTC for an unresolvable zone (pinned: zonedDateStartToUtcMs('2026-06-01', 'Not/AZone') equals the UTC answer) and returns NaN for unparseable input, while zonedWallClock returns null and lets each caller choose its own fallback. Whichever the import path adopts, it must be a deliberate choice stated in the PR, not whichever one the first import happens to inherit.

⛔ Held out of the same batch as #8684: both land in packages/rest and both may touch rest-server.ts. #8684 goes after this one merges.

---

Generated by Claude Code