Environment: Claude desktop 2.26454.2 (Electron 44.4.3, Chrome 152.0.7977.130), Windows 11, Windows time zone "Morocco Standard Time"
What happens
Times the app draws itself, such as the usage popover's "Resets …", are 1 hour ahead of local time. Morocco is on UTC+0 (no extra hour in 2026). The Windows clock is correct, but the app's bundled time zone data still puts Africa/Casablanca at UTC+1.
Evidence
- On the same machine, current Edge 154.0.4258.62 gives
new Date().toString() = ... GMT+0000 (Western European Standard Time) with Intl...timeZone = Africa/Casablanca. So newer Chromium time zone data is already correct.
- The app shows the same instant 1 hour later.
- No user-side override exists: Chromium on Windows ignores the
TZ environment variable (tested, with no effect), and the app has no time zone setting.
Expected
Times in the app match the system clock. This needs newer ICU/tz data, through an Electron/Chromium update or by refreshing icudtl.dat.
Workaround
Switch Windows to another UTC+0 zone with no daylight saving, "(UTC+00:00) Monrovia, Reykjavik".
Environment: Claude desktop 2.26454.2 (Electron 44.4.3, Chrome 152.0.7977.130), Windows 11, Windows time zone "Morocco Standard Time"
What happens
Times the app draws itself, such as the usage popover's "Resets …", are 1 hour ahead of local time. Morocco is on UTC+0 (no extra hour in 2026). The Windows clock is correct, but the app's bundled time zone data still puts Africa/Casablanca at UTC+1.
Evidence
new Date().toString()=... GMT+0000 (Western European Standard Time)withIntl...timeZone=Africa/Casablanca. So newer Chromium time zone data is already correct.TZenvironment variable (tested, with no effect), and the app has no time zone setting.Expected
Times in the app match the system clock. This needs newer ICU/tz data, through an Electron/Chromium update or by refreshing
icudtl.dat.Workaround
Switch Windows to another UTC+0 zone with no daylight saving, "(UTC+00:00) Monrovia, Reykjavik".