fix(desktop): timestamps follow the OS locale instead of en-US

[brzzdev]

Fixes #6178.

Problem

On the packaged desktop app, the default Timestamp format: Locale setting always renders US 12-hour times — 3:44 PM on a machine whose region asks for 15:44.

The app ships only the en-US Chromium locale pak (DESKTOP_ELECTRON_LANGUAGES, scripts/build-desktop-artifact.ts:629), and Chromium resolves its default Intl locale from the application locale rather than from the OS. Passing undefined to Intl.DateTimeFormat in the renderer therefore means en-US however the machine is configured, so the "locale" branch of getTimestampFormatOptions — which deliberately omits hour12 and defers to the runtime — silently means "US 12-hour" on desktop. DEFAULT_TIMESTAMP_FORMAT is "locale", so this is the out-of-the-box experience for every desktop user outside the US.

Measured inside the packaged renderer (0.0.33, macOS set to en_GB):

{
  intlDefaultLocale: "en-US",          // ← should be en-GB
  navigatorLanguages: ["en-US", "en-GB"],
  renderedLikeT3:  "4:04 PM",          // Intl.DateTimeFormat(undefined, { hour: "numeric", minute: "2-digit" })
  withExplicitEnGB: "16:04",
  timeZone: "Europe/London"            // ← correct
}

The time zone resolving correctly while the locale does not is the tell: the OS is reachable from the process, and it is specifically the application locale that the pak trim pins.

Fix

Read the OS locale in the main process with app.getSystemLocale() — which the pak trim does not affect, unlike app.getLocale() — expose it over the existing desktop bridge, and format timestamps with it. The bridge member follows getAppBranding: a sync sendSync getter, so the cached, synchronous formatter needs no async plumbing.

Web is unchanged: with no bridge present the resolver returns undefined and the browser keeps resolving its own locale, which is already correct there.

resolveTimestampLocale normalizes POSIX-style tags (en_GB → en-GB) and falls back to the runtime default rather than throwing if the host ever reports something ICU rejects, since the formatter backs every timestamp in the UI.

Before / after

Chat timestamps, rendered by the real client under each locale. Same fixture, same crop; only the locale the formatter receives differs.

Before (en-US — what desktop shows today)	After (OS locale en-GB)

A note on how these were produced, so the evidence is not overstated: the bug does not reproduce in a dev run, because electronLanguages is an electron-builder packaging option and pnpm start has every locale pak. These are the web client driven under a locale-pinned Chromium context — en-US for before, the OS locale en-GB for after — which is exactly the pair of locales the formatter receives on either side of this change. The IPC half is covered by types and by the getAppBranding precedent it mirrors, not by these images.

Surfaces

• Desktop — the only surface affected, and the only one changed.
• Web — unaffected; browsers resolve their own locale correctly, and the resolver returns undefined without a bridge.
• Mobile — unaffected; React Native has no Chromium pak trim.
• Contracts — DesktopBridge gains one optional member.
• Docs — no user docs describe timestamp formatting, so none changed.

Out of scope

Three other call sites format with an implicit locale and are wrong on desktop for the same reason. Left alone to keep this to one concern; happy to follow up:

• apps/web/src/components/settings/ConnectionsSettings.tsx:144
• apps/web/src/components/clerk/MobileClientsUserProfilePage.logic.ts:3
• packages/client-runtime/src/state/threadSettled.ts:300 (snooze preset labels)

Testing

resolveTimestampLocale is unit tested for the tag it picks and for the hour cycle that results, including the en-GB → 15:44 / en-US → 3:44 PM pair. ElectronApp.test.ts covers the OS-locale passthrough and the POSIX normalization. Targeted vp test run on both files (25 and 8 passing), plus typecheck and lint on the three touched packages.

Four other ElectronApp test stubs gained the new systemLocale member. Those four are among 22 desktop test files that fail to import in my environment on main — an unrelated vi.mock/electron issue, identical before and after this change — so they are type-correct but I could not execute them locally. ElectronApp.test.ts itself is not affected and runs green.

---

Written by Claude Opus 5 in T3 Code.

---

Note

Low Risk
Localized display-only timestamp formatting on desktop; web unchanged. Fallbacks avoid throws on bad locale tags.

Overview
Fixes packaged desktop timestamps always rendering as US 12-hour when Timestamp format: Locale is selected, because Chromium’s default Intl locale is pinned to en-US (only that locale pak ships).

The main process now reads Electron.app.getSystemLocale(), normalizes POSIX tags (en_GB → en-GB), and exposes the result via a new sync getSystemLocale IPC path on desktopBridge (mirroring getAppBranding).

In timestampFormat.ts, resolveTimestampLocale validates the host tag and feeds it into cached Intl.DateTimeFormat instances so wall-clock times follow the OS (e.g. 15:44 for en-GB). Without a bridge (web), behavior is unchanged (undefined → browser default). Invalid tags fall back instead of breaking the UI.

DesktopBridge gains optional getSystemLocale. Desktop test stubs pick up systemLocale on ElectronApp; new unit tests cover locale resolution and Electron passthrough/normalization.

^{Reviewed by Cursor Bugbot for commit 244ca16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix timestamp formatting to use OS locale instead of en-US

• Adds systemLocale to the ElectronApp service, reading Electron.app.getSystemLocale() and normalizing POSIX-style tags (e.g. en_GB → en-GB).
• Exposes the locale to the renderer via a new synchronous IPC method (getSystemLocale) and window.desktopBridge.getSystemLocale().
• Adds resolveTimestampLocale in timestampFormat.ts to validate the host-provided locale using Intl.DateTimeFormat.supportedLocalesOf, falling back to the runtime default on invalid or missing values.
• All Intl.DateTimeFormat timestamp formatters now use the resolved OS locale instead of an implicit en-US default.
• Behavioral Change: timestamps in the desktop app will now render according to the OS locale (e.g. 24-hour clock for en-GB), which may differ visually from previous output.

^{Macroscope summarized 244ca16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ebac7ab7-a9e2-4012-8f24-653766367fba

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved 0fd360a

This is a focused bug fix that makes desktop timestamps respect the OS locale instead of being hardcoded to en-US. The implementation is self-contained, well-tested, and properly handles edge cases like POSIX locale format normalization.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate 0fd360a

[brzzdev]

Pushed a follow-up commit for the review. Rebased onto latest main.

Fixed — mixed-language tooltips. Correct, and it was a regression this PR introduced. formatChatTimestampTooltip builds ${time}, ${day}${ordinalSuffix} ${month} ${year}, where the ordinal suffix and the day-before-month order are hardcoded English, so localizing the month alone really does yield 15:44, 4th Juni 2026. monthNameFormatter is back on the runtime locale with a comment recording why, which also drops a line this fix never needed. Localizing that whole label is a separate change.

Fixed — adapter boundary. POSIX normalization (en_GB → en-GB) moved to ElectronApp.systemLocale, where the macOS NSLocale behavior that causes it belongs, and the packaging exposition left the renderer. The renderer still falls back rather than throwing on a tag it cannot use — that guard is not platform knowledge, it is that this formatter backs every timestamp in the UI and a RangeError there would blank all of them.

Fixed — desktop coverage. Two tests added to ElectronApp.test.ts, for the passthrough and for the normalization. Worth correcting one point: that file is not among the desktop tests that fail to import, and it runs green locally (6 → 8). The import failures are a separate pre-existing vi.mock/electron issue affecting 22 files identically on main; four of them happen to hold ElectronApp stubs that needed the new member.

Not doing — user documentation. docs/user/ has no page covering timestamps, appearance, or the Settings surface this lives on, so there is nothing to update; the rule points at behavior changes a user would notice, and this restores the behavior the existing setting already promises. Writing a new user-docs page to carry a bug fix is a second concern, and I would rather you tell me you want one than have it arrive unasked.

Not doing — shared ElectronApp test builder. Agreed on the smell, but collapsing four unrelated test files into a shared stub is exactly the "also" that gets a PR split. Happy to do it separately if you want it.

Verification after the change: ElectronApp.test.ts 8 passing, timestampFormat.test.ts 25 passing, typecheck and lint clean on the three touched packages. The before/after images are unaffected — they show formatShortTimestamp in the chat timeline, not the tooltip.

[macroscopeapp]

One consistency issue found in apps/web/src/timestampFormat.ts: the day-aware timestamp now mixes the host locale (time) with the runtime-default locale (numeric date). Details inline.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The English-tooltip exception is well justified, but the two numeric date formatters below (numericDateFormatter, numericDateWithYearFormatter) are still built with undefined while the time formatter now uses timestampLocale. formatDayAwareTimestamp concatenates the two, so on packaged desktop — where the runtime default is pinned to en-US — an en-GB machine renders 8/13 15:44 instead of 13/08 15:44, i.e. UK hour cycle with US month/day order in the same label. That also contradicts the formatDayAwareTimestamp docstring, which promises "locale digit order".

These formatters emit no English words, so the reason given here for monthNameFormatter doesn't apply to them; suggest passing timestampLocale to both (they are declared after the timestampLocale binding, so no reordering is needed), or adding a short note if leaving them on the runtime default is deliberate.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 244ca16. Configure here.}

[cursor]

Chat dates stay US-ordered

Medium Severity

formatDayAwareTimestamp now formats the time with timestampLocale but still builds the date prefix via numericDateFormatter and numericDateWithYearFormatter on the runtime default. On packaged desktop that default stays en-US, so older chat timestamps pair an OS-locale time with US M/D order. Unlike monthNameFormatter, these numeric formatters have no English-only scaffolding that would make the host locale unsafe.

Additional Locations (1)

• apps/web/src/timestampFormat.ts#L162-L165

 

^{Reviewed by Cursor Bugbot for commit 244ca16. Configure here.}

[juliusmarminge]

The current head still has the date-prefix locale bug identified by Macroscope and Bugbot. I prepared and verified the focused fix, but maintainerCanModify is disabled and GitHub rejected the guarded push to the fork.

Please update both numericDateFormatter and numericDateWithYearFormatter in apps/web/src/timestampFormat.ts to construct Intl.DateTimeFormat(timestampLocale, ...), and add coverage proving an en-GB desktop host renders an older chat timestamp as 12/08 15:44 rather than mixing 8/12 with a 24-hour time.

Verified locally against head 244ca169ca860663e7229c1b6e9f176c9c06a9f0: 39 focused tests passed; targeted lint and format passed; web, desktop, and contracts typechecks passed. Auto-merge should remain disabled until the actionable review is fixed; GitHub currently rejects the disable-auto-merge mutation for this PR.