[Bug] Windows desktop: "browser time zone is unavailable" blocks chat with British Columbia Standard Time

[terence264]

Summary

On Windows using the new British Columbia Standard Time zone, the official desktop app refuses every attempted chat message with:

browser time zone is unavailable

The installed Electron runtime cannot resolve the Windows zone to a non-empty IANA identifier. The client treats this missing metadata as a fatal error before sending the prompt RPC. This was encountered after updating the desktop app; the first affected Harness release has not been bisected.

Environment

• Official DeepSeek Harness desktop: 0.2.0-rc.2, Windows x64
• Embedded runtime, measured using the installed app executable in Electron run-as-Node mode: Electron 44.0.0, Node 24.18.1, ICU 78.2, tzdata 2025c
• Windows time-zone ID: British Columbia Standard Time (the new UTC-07:00 Pacific Time / British Columbia entry)
• Source inspection: master at 571902028a75c64c1d767f4ae5fd099485f0ddf0

Microsoft documents the new BC zone in the September/October 2026 Windows updates: official guidance.

Reproduction

1. Use a Windows installation configured with British Columbia Standard Time.
2. Launch the official desktop app normally, without an app-specific TZ override.
3. Open a conversation and send a simple message.

Actual result: the message fails with the error above and no model response is produced.

An isolated probe using the installed desktop executable's own Electron runtime returns undefined for:

new Intl.DateTimeFormat().resolvedOptions().timeZone

The observed offset was also 480 minutes (UTC-08:00), not the expected 420 (UTC-07:00). This runtime probe is separate from a direct renderer-console measurement; the actual desktop failure and subsequent successful chats were verified through the UI.

Relevant source

• Client sampler: resolvedClientTimeZone() throws when the runtime returns undefined or an empty string.
• Prompt call sites: the helper runs before both ordinary session and continuable-subagent prompt RPCs. Ordinary chat was reproduced locally; subagent impact is inferred from this shared call site.
• Request type: clientTimeZone is already optional.
• Host prompt handling: omission is accepted, while an explicitly supplied invalid zone is rejected.
• Time-context policy: missing browser-zone information already has an explicit unavailable/ask-for-clarification state.
• Existing sampler test currently expects a throw for missing or empty zones.

This is related to discussion #5403, but a different failure: that report sends an unsupported non-empty alias to the Host; this one fails in the client before the RPC because no zone was resolved.

Expected behavior / suggested direction

Ordinary chat should remain usable when optional browser time-zone metadata is unavailable. The request should retain that unknown state rather than silently assigning UTC, Vancouver, or the server's zone as the user's location.

A possible focused change is to let the client sampler return undefined for the observed missing/empty results and omit clientTimeZone from those requests. Keep the existing Host validation for explicitly supplied invalid zones. Any downstream display fallback should remain distinct from the user's unknown time zone. Updating the bundled ICU Windows-to-IANA mapping and time-zone rules would address the underlying platform issue as well.

Suggested regression coverage:

• A valid runtime zone is preserved.
• Missing/empty runtime zones do not prevent ordinary or continuable-subagent prompt submission.
• Missing zone information stays unavailable in the model-facing policy.
• Explicitly invalid non-empty zones are still rejected by the Host.

This is a proposed direction based on the current request types and handlers, not a claim that an upstream source patch or its complete test suite has been run.

Local mitigation and verification

For diagnosis and to restore this installation, only the Harness process was launched with TZ=America/Vancouver plus official Unicode ICU timezone resources 2026e. Windows settings, global environment variables, and installed Harness application files were left unchanged.

Same installed Electron runtime	Default zone	Current offset	Offset at 2026-12-01T12:00:00Z
Original launch environment	unavailable	UTC-08:00	UTC-08:00
Only TZ=America/Vancouver	America/Vancouver	UTC-07:00	UTC-08:00
App-specific TZ + ICU 2026e resources	America/Vancouver	UTC-07:00	UTC-07:00

Updating timezone resources alone did not restore automatic Windows-zone detection in this local test; the explicit app-local mapping was also needed. Conversely, setting TZ alone left the old winter rule in place.

With the combined mitigation, the actual desktop app completed two simple chat turns successfully, including one after a full exit and relaunch. These checks validate the local mitigation, not the proposed source change above.

Posting here rather than opening an external PR, as requested in the contribution guide.

[argszero]

Every source claim in your report checks out on master @ 571902028a, and the extra fact you could not see from the UI is that no RPC is ever issued — so the failure has no host-side trace at all.

Source confirmation, in the order the request travels.

• packages/api/session-controller/src/client/time-zone.ts:5-14 — the sampler reads Intl.DateTimeFormat().resolvedOptions().timeZone and throws browser time zone is unavailable when the value is not a non-empty string.
• Both call sites run it: ordinary prompt at client/sessions/session.ts:270, continuable-subagent prompt at :298 — your inference from the shared helper is right, both paths are affected.
• The host already tolerates omission: packages/api/session-controller/src/index.ts:471-479 maps request.clientTimeZone === undefined to undefined and only rejects a value that was supplied and fails canonicalization (session/invalid-time-zone).
• The downstream policy already models the unknown case: packages/context/time-context/src/request-zone.ts:56 returns { kind: 'missing' } and :75 renders "Browser time zone for this request: unavailable." So nothing downstream needs a zone to be invented.
• The throw is pinned by a test, not incidental: packages/api/session-controller/tests/time-zone.client.spec.ts asserts it for both undefined and '' via it.each. Your proposed change is therefore a deliberate test change (the case should become "omits the field"), which is worth saying in the report so it does not read as a missing test.

The fact the UI cannot show you: the throw is synchronous and sits before the first await in prompt() (session.ts:270-272, where promptAttempted and firstPromptPendingTurn have already been set at :264-269). No request reaches the host, which is why there is no server-side error to correlate and why the message you see is the client's own literal.

One design caution for the fix: canonicalClientTimeZone accepts UTC or an IANA Area/Location name and canonicalizes it (packages/util/time/src/index.ts:20-33, README packages/util/time/README.md:12). So when the runtime cannot resolve a zone, the client must omit clientTimeZone rather than substitute a placeholder — sending UTC would record a claim about where the user is, which is the thing your "expected behavior" section asks to avoid. Omission is the only shape that preserves "unknown".

On the plugin question (this repository's tracker is off, so people ask whether a plugin can carry it): to my reading it cannot, and it is worth recording why — the failing call is inside the client bundle's own module, and a registered client module cannot intercept another bundle's static import; the only remaining seam would be a process-wide patch of Intl.DateTimeFormat.prototype.resolvedOptions, which would fabricate a zone for a user whose zone genuinely is unknown. So this one is a client change, and your suggested regression list (valid zone preserved; missing zone does not block ordinary or continuable-subagent submission; unknown stays unavailable in the model-facing policy; explicitly invalid non-empty zone still rejected) is the right shape for it.

Thanks for the two-part mitigation table as well — "TZ alone moved the offset but left the old winter rule, and ICU resources alone did not restore Windows-zone detection" is the part that makes the case reproducible for someone without that Windows build.

[freeborn99]

I can confirm this bug also impacts Windows users on the new permanent Alberta Time zone (Alberta Standard Time) just inroduced. Because the embedded Electron runtime cannot map this new Windows registry entry to a valid IANA identifier, it throws the fatal client-side error. As a temporary workaround, you can bypass the crash by opening PowerShell and forcing a recognized timezone variable when launching the app:

$env:TZ="America/Edmonton"
& "C:\Program Files\DSH Desktop\DSH Desktop.exe"

cheezy but works for now.

[nuochan]

Confirmed on Windows with the new BC zone — TZ override works, client-side throw is the only blocker

Environment: Windows, time zone set to "British Columbia Standard Time", DSH desktop (latest release).

Reproduces as reported. With TZ unset, the Electron runtime (run via ELECTRON_RUN_AS_NODE=1, so the runAsNode fuse is enabled in this build) prints:

undefined

Setting TZ fixes the runtime value:

$env:TZ="America/Vancouver"
& "DeepSeek Harness.exe" probe.js
America/Vancouver
Dec 1, 2026, GMT-07:00

The December 2026 offset printing GMT-07:00 means the bundled ICU tzdata is already current — for the new BC zone this is purely the Windows zone-ID to IANA mapping gap, not a tzdata problem.

Launcher test (set TZ=America/Vancouver before start, then launch the app normally) — chat succeeds, no "browser time zone is unavailable". So TZ does reach the renderer-side sampler; the throw in packages/api/session-controller/src/client/time-zone.ts is the only thing preventing a working session. This also answers the open question of whether the renderer sees the override: it does.

Suggested fix: when resolvedOptions().timeZone is undefined or empty, omit clientTimeZone and let the host's existing "unavailable" time-context state handle it, rather than throwing client-side. The host already tolerates the omission, so this should be a small change. A Windows-zone to IANA fallback (e.g. "British Columbia Standard Time" -> America/Vancouver, "Alberta Standard Time" -> America/Edmonton) would be a longer-term option once Electron/Chromium upstream adds the new IDs.