[Bug]: Desktop "Timestamp format: Locale" always renders US 12-hour times because the packaged app ships only the en-US Chromium locale

[brzzdev]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Use a machine whose OS region is a 24-hour locale but whose language is English — e.g. macOS with AppleLocale = en_GB and AppleLanguages = ("en-GB").
2. Install and launch the packaged desktop app (0.0.33).
3. Leave Settings → Timestamp format on its default, Locale.
4. Look at any message timestamp in a thread.

Expected behavior

With Timestamp format: Locale, times follow the operating system's locale. On an en-GB machine that is 15:44.

Actual behavior

Times render in US 12-hour form — 3:44 PM — on every surface, regardless of the OS locale.

The cause is that the packaged desktop app ships only the en-US Chromium locale:

// scripts/build-desktop-artifact.ts:629
export const DESKTOP_ELECTRON_LANGUAGES = ["en-US"] as const;

which is passed straight to electron-builder at scripts/build-desktop-artifact.ts:1542. The installed bundle confirms the trim — exactly one locale pak survives:

$ ls "/Applications/T3 Code (Alpha).app/Contents/Resources/"
app-update.yml   app.asar   app.asar.unpacked   en.lproj   icon.icns   resource-monitor

Chromium picks its application locale from the available pak files, and the renderer's default Intl locale follows that application locale rather than the OS regional settings. With every pak but en-US stripped, navigator.language and Intl.DateTimeFormat().resolvedOptions().locale are pinned to en-US inside the desktop renderer.

That is exactly the path the timestamp helper takes. getTimestampFormatOptions deliberately omits hour12 for the "locale" setting and defers to the runtime locale (apps/web/src/timestampFormat.ts:13-15), and the formatter is constructed with undefined as its locale argument (apps/web/src/timestampFormat.ts:35-36). On desktop that undefined can only ever resolve to en-US, so "locale" silently means "US 12-hour".

DEFAULT_TIMESTAMP_FORMAT is "locale" (packages/contracts/src/settings.ts:19), so every desktop user outside the US gets the wrong hour cycle out of the box.

The same undefined-locale assumption also affects other desktop-rendered date strings, e.g. timeStyle: "short" in apps/web/src/components/settings/ConnectionsSettings.tsx:144 and apps/web/src/components/clerk/MobileClientsUserProfilePage.logic.ts:3, and the snooze preset labels in packages/client-runtime/src/state/threadSettled.ts:300.

Impact

Cosmetic issue

Version or commit

0.0.33 (packaged desktop app); reproduced against main @ 6676f9c

Environment

macOS 26.6.1 (build 25G76), Apple Silicon, Electron 41.5.0, AppleLocale = en_GB, AppleLanguages = ("en-GB"), AppleICUForce24HourTime unset. Desktop app 0.0.33.

Workaround

Set Settings → Timestamp format to 24-hour explicitly. That branch passes hour12: false outright (apps/web/src/timestampFormat.ts:17-20), so it produces 15:44 even under the pinned en-US locale. It does not help the surfaces that bypass the setting, and it does not fix date ordering or other locale-sensitive strings.

Possible fix

Two independent options, either of which resolves the report:

1. Feed the real OS locale to the renderer. app.getSystemLocale() and app.getPreferredSystemLanguages() report the true OS values and are unaffected by the pak trim (unlike app.getLocale(), which returns the trimmed application locale). Pass one of those through to the renderer and use it as the explicit first argument to Intl.DateTimeFormat instead of undefined. This keeps the bundle small and fixes every undefined-locale call site at once.
2. Ship more locale paks by widening DESKTOP_ELECTRON_LANGUAGES. Simpler, but trades install size for the fix and only helps locales that are explicitly listed.

Option 1 looks like the smaller and more complete change. Happy to open a PR for it if that is wanted — flagging first per CONTRIBUTING.

[brzzdev]

Confirmed empirically, evaluated inside the packaged app's own renderer process (0.0.33, macOS en_GB):

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

renderedLikeT3 uses exactly the options getTimestampFormatOptions produces for the "locale" setting, and it reproduces the reported 4:04 PM. Passing an explicit en-GB to the same call yields 16:04.

Two details worth noting:

• The time zone resolves correctly while the locale does not. The OS settings are reachable from the process; it is specifically the application locale that is pinned by the pak trim, and Intl follows it.
• The real OS language is present but not first. Chromium composes navigator.languages as [application locale, ...OS preferred languages], so en-GB is sitting in the list at index 1 while en-US wins as the default. This is what makes undefined the wrong locale argument on desktop specifically.

That also means the fix does not strictly require new IPC — but reading the OS value from the main process via app.getPreferredSystemLanguages() / app.getSystemLocale() is far more honest than indexing into navigator.languages and hoping the ordering holds.

One consequence for anyone picking this up: it will not reproduce in a dev run. electronLanguages is an electron-builder packaging option, so pnpm start uses the full Electron framework with every locale pak present and resolves en-GB correctly. Launching dev Electron with --lang=en-US should simulate the packaged behaviour for testing.