Export download filename is stamped in the process-local timezone, not the business timezone

[os-zhuang]

Found while implementing #8373 (export cell rendering); filed rather than fixed there, because it changes a different user-visible surface (the suggested download filename) and #8373's fix direction named only the cell formatter.

What

exportContentDisposition() in packages/rest/src/export-format.ts builds the download's filename timestamp with local-time getters:

const stamp =
 `${now.getFullYear()}${pad(now.getMonth() + 1)}${pad(now.getDate())}` +
 `-${pad(now.getHours())}${pad(now.getMinutes())}${pad(now.getSeconds())}`;

getFullYear() / getHours() read the process TZ, which is a deployment-host fact, not the caller's business timezone. The route resolves the business timezone one frame up (resolveExecCtx gives an ExecutionContext carrying timezone, the platform-default to global to tenant cascade) and does not pass it here.

Why it matters now

Before #8373 this was the quieter half of a self-contradiction the issue reported as evidence: the filename read the host clock while the file's contents read UTC. #8373 moves the contents onto the business timezone. The filename is now the only part of an export still on the host clock, so the two disagree exactly when TZ is not the business timezone — a container at TZ=UTC serving an Asia/Shanghai tenant downloads orders-20260731-220000.csv whose first row is 2026-08-01 06:00:00. The reported deployment happened to set TZ=Asia/Shanghai, which is why the filename looked right there.

Not a regression introduced by #8373 — the local-time stamp predates it — but #8373 is what makes it the odd one out.

Suggested direction

Thread the same ExecutionContext.timezone into exportContentDisposition() and take the stamp's calendar components from it, falling back to today's behaviour when no timezone is resolved. Note the fallback question is worth deciding explicitly rather than assuming: for the contents the compatible fallback is UTC, but this function has always used process-local, so "no timezone" here means keeping local, not switching to UTC — otherwise every deployment without a configured timezone sees its filenames change.

Repro

Unit level, no server needed:

TZ=UTC node -e "console.log(new Date('2026-08-01T02:00:00Z').getHours())" # 2
TZ=Asia/Shanghai node -e "console.log(new Date('2026-08-01T02:00:00Z').getHours())" # 10

exportContentDisposition('orders', undefined, 'csv', new Date('2026-08-01T02:00:00Z')) yields a different stamp per host TZ for the same instant and the same tenant.

Scope

• packages/rest/src/export-format.ts — exportContentDisposition
• its call site in the export route in packages/rest/src/rest-server.ts
• packages/rest/src/export-format.test.ts pins the current local-time behaviour (const NOW = new Date(2026, 6, 14, 15, 30, 45)), so those expectations move with the fix.

Related: #8373.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/rest/src/export-format.ts (exportContentDisposition) ⇒ domain:cli. Queued as Bug: after #8373 the filename is the only export surface still on the process clock, so it disagrees with the file's own contents whenever host TZ ≠ business timezone. Note the card's own fallback caution — "no resolved timezone" here means keep process-local, not switch to UTC. Sibling of #8485 (import half); same packages/rest surface, serial or same-dispatch per the lane seat's call.

Size/model suggestion: S, mechanical with the pinned test moving.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 1 (concurrency raised 3 → 5 mid-round on maintainer instruction 「并发加到5」)
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8484-export-filename-business-timezone
Worktree: objectstack-issue-8484
Domain: domain:cli
File surface: packages/rest/src/export-format.ts + export-format.test.ts; and only if a resolved timezone must be threaded in, the single exportContentDisposition call site in packages/rest/src/rest-server.ts (:105 import, :7949 region). Anything else in rest-server.ts is a breach (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus
Serial constraints cleared: export-format.ts carries no in-flight claim. Premise re-verified on origin/main @ 3508678 rather than taken from the card — export-format.ts:71-73 builds the stamp from now.getFullYear()/getMonth()/getDate()/getHours()/getMinutes()/getSeconds(), all process-local getters, which is exactly the defect.

⚠️ Two same-package overlaps declared, both file-disjoint by construction:

• [finding] packageService.delete's driver fault is answered as 400 PACKAGE_DELETE_FAILED — the same mislabelling #8131 fixed for publish, on the sibling route #8275 (this seat, in flight) edits packages/rest/src/package-routes.ts, DELETE arm only — a different file, and its order forbids reaching further into packages/rest.
• types: isUniqueViolationError claims SQLite's UNBACKED-conflict-target error — a superstring collision on "UNIQUE constraint", the exact inversion the predicate's own warning names #8590 (this seat, in flight) changes isUniqueViolationError in packages/types, whose consumers include packages/rest/src/import-runner.ts — the import half. This card is the export half and must not touch import.
• Bulk import reads a naive datetime cell in the process-local timezone, so an export/edit/re-import round trip shifts the instant #8485 is this card's declared sibling (the import half of the same timezone defect) and is deliberately left unclaimed and unassigned — same packages/rest surface family, and it additionally sits near import-runner.ts, which types: isUniqueViolationError claims SQLite's UNBACKED-conflict-target error — a superstring collision on "UNIQUE constraint", the exact inversion the predicate's own warning names #8590's verdict change reaches. It is the safer of the twins to run second, not in parallel.

Model note: triage suggested S/mechanical. Size accepted, model raised to opus with reason — the card's fallback rule inverts the intuitive answer ("no resolved timezone" means keep process-local, ⛔ not switch to UTC), and getting it backwards produces a silently wrong filename in every deployment whose host TZ is set. That is a quiet-wrong-answer trap, not a mechanical edit.

Dispatched under the maintainer's direct channel, verbatim instruction: 「identity ＋ services ＋ cli 优先处理 bug」.

---

Generated by Claude Code