Agents report timestamps in UTC because nothing ever told them the user's timezone — and no prompt has a clock

[serge-ivo]

The report

When the leader agent replied it told me the time in UTC. I don't care about UTC. I need all
timestamps in my time zone. Do I have to specify it?

Real example, Coder Lead 2026-08-06:

"The FAS cleanup run is active at iteration 2 (started at 22:33:34 UTC)"
"the run completed at 22:34:19 UTC today"

Answer: no, you should not have to — and the agent is not at fault

Two facts, both verified:

• No user timezone is stored anywhere. Not in users.preferences (which exists since [docs] Update Coder docs for runner-node picker, engines, and package paths #211 for
  voice and translation), not in user_profile, not in any migration.
• No prompt tells an agent what time it is. Grepping agent-think.ts and agent-do-prompt.ts
  for a clock or a locale returns nothing.

So the agent reads ISO UTC strings out of tool results and labels them UTC. Given what it has, that
is the correct answer — inventing a local time would be worse. The gap is that nobody ever told
it where the user lives.

The platform already has the machinery

lib/triggers.ts validates timezones (isValidTimeZone) and stores one per trigger — that
landed with #18's timezone-aware schedules. What is missing is a user-level default, which is
the thing every other surface needs.

The browser knows it for free: Intl.DateTimeFormat().resolvedOptions().timeZone.

Design: format at the source, do not make the model convert

The obvious fix — tell the agent the timezone and let it convert — is the wrong one. Timezone
arithmetic in a language model is exactly the class of thing it does almost right: DST edges,
day boundaries, "yesterday" near midnight. A wrong-by-one-hour timestamp presented confidently is
worse than UTC presented honestly.

Instead:

1. Capture timezone into users.preferences — defaulted from the browser on first load,
   editable on the Preferences page ([docs] Update Coder docs for runner-node picker, engines, and package paths #211's home for exactly this kind of account-level setting).
2. Format tool outputs at the source. Run timings, board timestamps and subordinate_status
   render in the user's zone before the model ever sees them, with the zone named
   (22:33:34 UTC → 8:33:34 am AEST). The model then repeats a correct string rather than
   computing one.
3. Tell the agent the current time and zone in the prompt as well, so it can reason about
   "today" and "overnight" — but as context, not as a conversion instruction.

This is the same principle as rendering a technicality slider as a described band rather than
"70/100" (#223): give the model language it can only repeat, not arithmetic it can get subtly wrong.

Also worth covering

The console renders timestamps too (formatDateTime in the SDK). Those should use the same stored
preference rather than the browser default, so a user who overrides the zone sees it applied
consistently rather than in the chat only.

Verification

• A fresh account has its timezone populated from the browser without being asked.
• The Lead reports run times in the user's zone, named, with no UTC anywhere in the reply.
• Changing the timezone in Preferences changes both chat replies and console timestamps.
• A user whose zone observes DST gets correct local times either side of a transition — the case
  that catches naive offset arithmetic.

[serge-ivo]

Fixed in c4394ad (CI green, deployed with 99bf6d8).

Where the zone comes from: users.preferences.timezone — the account blob from #211, where voice and translation already live. A timezone is a property of the person, and that blob is the one place the owner already maintains for things that follow them across agents. No migration: the column has existed since 0071. Validated with isValidTimeZone from lib/cron-time.ts, the same validator triggers have used since #18, so the platform has one timezone vocabulary rather than two.

Rejected user_profile (the apply pipeline's PII — only people using the job agent would ever fill it in) and a typed settingsSchema field (declared per agent, answered per instance, so four agents means answering four times and any agent whose creator forgot still says UTC). A browser-supplied value is the right way to seed the stored one, not to be it: it changes when you travel, is absent on every non-browser path (cron, the pump, MCP), and cannot be corrected.

Unset stays first-class. There is no default zone, and parseAccountPreferences keeps undefined and "UTC" distinguishable — one is a user nobody asked, the other a user who really is there. PUT /v1/preferences rejects an unresolvable zone with 400 rather than coercing it, and null/"" clears back to unset. Unset loses the localisation, never the clock: a UTC time is a fact, a guessed local time is not.

Formatted at the source, per the ticket's design. lib/work-report.ts renders the wall clock where the epoch millisecond and the zone are both in hand; check_work pays one lookup for the same zone, because that module's contract is that it and the prompt block never tell different stories about one run. The prompt hands over a pre-formatted string plus the current offset and bounds conversion to times near now — words to repeat rather than DST arithmetic to get subtly wrong, the same principle as #223's described bands.

New pure module lib/agent-clock.ts (+ tests pinned to fixed instants, including either side of a DST transition and a +05:45 zone).

Console (#336) reconciles for free. SystemMessage.tsx renders browser-local and needs no change: with a zone set, agent prose is local too. Remaining item for the console lane — seed timezone from Intl.DateTimeFormat().resolvedOptions().timeZone on first load via PUT /v1/preferences, and pass preferences.timezone (from GET /v1/preferences) as the timeZone option in lib/messageStamp.ts's stampTitle, so an explicit override wins over the browser default in both halves.