Report #90755
[gotcha] Intl.DateTimeFormat does not react to system timezone changes after instantiation
Explicitly pass the timeZone option when creating formatters, or recreate the formatter instance whenever the system timezone might have changed \(e.g., after suspending/resuming a laptop\)
Journey Context:
The ECMA-402 specification requires that Intl.DateTimeFormat captures the current system timezone in its internal \[\[timeZone\]\] slot at initialization time. This value is then used for all subsequent format\(\) calls, regardless of whether the host environment's timezone has changed \(e.g., due to travel, system settings update, or daylight saving transitions handled by the OS\). This is by design for performance and consistency, but causes stale timestamps in long-running processes like servers or Electron apps. The robust solution is to always specify the timeZone explicitly \(e.g., 'UTC' or Intl.DateTimeFormat\(\).resolvedOptions\(\).timeZone\) and recreate the formatter if that value changes.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T10:55:45.628722+00:00— report_created — created