Skip to content

fix(runtime): use local timezone for turn-tail date - #540

Merged
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date
Jul 5, 2026
Merged

fix(runtime): use local timezone for turn-tail date#540
Astro-Han merged 2 commits into
mainfrom
fix/runtime-turn-tail-local-date

Conversation

@Astro-Han

@Astro-Han Astro-Han commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Summary

formatDate in session-environment-prompt used toISOString().slice(0,10) (UTC), so near local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected "Today's date" was one day behind the user's calendar day, affecting date-sensitive answers. Format via the local Date methods (getFullYear / getMonth + 1 / getDate) so the date matches the process timezone. Both desktop and CLI turn-tail use this fragment, so both are fixed.

Why

Closes #538. The shared turn-tail date fragment reported the UTC day, not the user's local calendar day; near local midnight this was off by one. Issue #538 deferred this from PR #531 to keep the date-fragment timezone semantics in a focused change.

Scope

Changed:

  • packages/runtime/src/system-prompt/session-environment-prompt.ts: formatDate switches from toISOString().slice(0,10) to local getFullYear / (getMonth + 1) / getDate with padStart. No new public API.
  • packages/runtime/src/__tests__/session-environment-prompt.test.ts: spawn a child with TZ=Asia/Shanghai (cross-midnight: 16:30Z -> 2026-05-30) and TZ=UTC (midday: 12:34Z -> 2026-05-29), calling the fragment WITHOUT a timezone arg to lock the real default production path.
  • apps/desktop/src/main/__tests__/session-environment-prompt.test.ts: date assertion relaxes to a YYYY-MM-DD format match (the value now follows the process timezone).

Not included:

  • A timeZone input option — dropped per review; no production caller needed it and it only widened the public API for tests.
  • Desktop renderer pre-existing fails (Daily Review className + renderer error boundary) — present on main without this branch, tracked separately.

Verification

  • runtime: 820 pass (new TZ-child tests green; 1 pre-existing skipped).
  • cli: 74 pass (only asserts the Today's date: line exists, not the value).
  • typecheck: green.
  • desktop: 1933 pass, 2 fail — both pre-existing on main (confirmed by running desktop tests on the main checkout without this branch: same 2 fail, same counts).

User-facing impact

Desktop and CLI/TUI now report the user's local calendar date in the per-turn environment tail instead of the UTC date. No setting, API, or migration needed.

Reviewer notes

Default-path coverage: the cross-midnight test runs in a child process with TZ=Asia/Shanghai and calls the fragment with no timezone arg, so it exercises the same path desktop/CLI use (process local timezone). The 2 desktop fails are unrelated to this change; flag if you'd like a separate issue for them.

Astro-Han added 2 commits July 5, 2026 11:57
formatDate built "Today's date" with toISOString().slice(0,10) (UTC), so near
local midnight (UTC+8 00:30 = UTC 16:30 previous day) the injected date was one
day behind the user's calendar day. Add an optional timeZone to
SessionEnvironmentPromptInput (defaults to the process local timezone) and
format via Intl.DateTimeFormat so the date matches the user's day. Desktop
test pins now use timeZone: 'UTC' for a stable assertion; new runtime test
covers the cross-midnight case (Asia/Shanghai 16:30Z -> 2026-05-30) and the
UTC midday case.

Closes #538.
…lt TZ path

- P3: drop SessionEnvironmentPromptInput.timeZone — no production caller
  passed it, so it only widened the public API for tests. Production now
  formats in the process local timezone directly.
- P3: replace Intl.DateTimeFormat.formatToParts with getFullYear /
  (getMonth + 1) / getDate + padStart — same local YYYY-MM-DD, less code.
- P2: the cross-midnight test now spawns a child with TZ=Asia/Shanghai and
  calls the fragment WITHOUT a timezone arg, locking the real default
  production path (desktop/CLI never pass timeZone) instead of a test-only
  arg. Desktop date assertion relaxes to a YYYY-MM-DD format match since the
  value now depends on the process timezone.

Refs #538.
@Astro-Han
Astro-Han merged commit 260e232 into main Jul 5, 2026
@Astro-Han
Astro-Han deleted the fix/runtime-turn-tail-local-date branch July 14, 2026 05:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

turn-tail date fragment uses UTC, off-by-one near local midnight

1 participant