deepseek-ai/deepseek-harness · error

browser time zone is unavailable

Error message

browser time zone is unavailable

What it means

resolvedClientTimeZone() samples the browser's IANA zone through new Intl.DateTimeFormat().resolvedOptions().timeZone to attach provenance to outbound prompt RPCs, and throws when the runtime yields anything but a non-empty string. This is an environment-capability error: the engine lacks timezone data (small-ICU builds, stripped WebViews, old browsers) or an Intl polyfill omits timeZone, so no canonical zone can be reported and the library refuses to invent one.

Source

Thrown at packages/client/runtime/src/client/time-zone.ts:11

/** Browser-owned time-zone sampling for prompt RPC provenance. */

/**
 * Resolve the current browser IANA zone for one outbound operation.
 * @returns The browser-provided canonical zone.
 * @throws when the runtime cannot provide a non-empty zone.
 */
export function resolvedClientTimeZone(): string {
  const timeZone = new Intl.DateTimeFormat().resolvedOptions().timeZone
  if (typeof timeZone !== 'string' || timeZone.length === 0) {
    throw new Error('browser time zone is unavailable')
  }
  return timeZone
}

View on GitHub (pinned to b150a551b8)

Solutions

1. Run the environment with full ICU and timezone data: upgrade the browser, use a full-icu Node build (or install full-icu / tzdata in the image), and set a valid TZ
2. Preflight the capability once at boot — String(new Intl.DateTimeFormat().resolvedOptions().timeZone || '').length > 0 — and route to an explicit zone when it fails
3. Catch the throw at the call site and send a user-chosen explicit zone instead of the sampled one
4. Do not paper over it with a silent default inside shared code; keep the fallback explicit where the zone is consumed

Example fix

// before
const zone = resolvedClientTimeZone()

// after — preflight the capability, fall back to an explicit zone
const sampled = new Intl.DateTimeFormat().resolvedOptions().timeZone
const zone = typeof sampled === 'string' && sampled.length > 0 ? sampled : 'UTC'

const sampled = new Intl.DateTimeFormat().resolvedOptions().timeZone
const zone = typeof sampled === 'string' && sampled.length > 0
  ? resolvedClientTimeZone() // guaranteed to succeed now
  : 'UTC' // explicit fallback; this runtime cannot produce a sampled zone

function hasResolvedTimeZone(): boolean {
  const tz = new Intl.DateTimeFormat().resolvedOptions().timeZone
  return typeof tz === 'string' && tz.length > 0
}

When it happens

Trigger: Any prompt path that calls resolvedClientTimeZone() in a runtime whose Intl cannot resolve a zone: Node built with small-icu, minimal embedded WebViews, old Safari or Chrome, or jsdom/partial-Intl polyfill environments where resolvedOptions().timeZone is undefined or an empty string.

Common situations: Running the web client in a stripped-down embedded browser; CI or container images shipping small-icu Node without tzdata; older mobile WebViews; test environments that polyfill Intl partially.

AI-assisted analysis of deepseek-ai/deepseek-harness@b150a551b8 (2026-08-24). Data as JSON: /api/errors/b982daa32725fdde. Report an issue: GitHub.