Intl.DateTimeFormat default time zone mapping: missing explicit mapping between Chrome locale preferences and OS time zone

Question

Background
When a web page creates an Intl.DateTimeFormat instance without specifying the timeZone option, Chrome falls back to the host operating system’s time zone. The mapping between Chrome’s language preferences and the OS time zone is not defined in the ECMAScript specification or the Chrome documentation, leading to inconsistent time zone inference across browsers, extensions, and OS platforms.
Current Constraints
Chrome exposes the chrome.timeZone API only on Chrome OS, and its persistence across reboots and effect on running web pages are undocumented. The browser bundles ICU time‑zone data, but there is no public hook to refresh the database without restarting Chrome.
Unresolved Decision
Because the default timeZone behavior is implicit, developers cannot guarantee that a page’s date rendering will reflect the user’s locale or a recent OS time‑zone change without a page reload.
Questions
1. Does Chrome always use the OS time zone when timeZone is omitted, regardless of the user’s language preference?
2. Can an extension on Chrome OS reliably change the time zone used by web pages via chrome.timeZone, and does that affect pages already loaded?
3. Is there a public API or flag that forces Intl.DateTimeFormat to re‑read the OS time zone after a system change?

Zoha · Answer

Answer
Chrome always uses the operating system’s current time zone when Intl.DateTimeFormat is created without an explicit timeZone option, independent of the browser’s language preferences.
Confirmed facts

This behavior comes from the ICU library bundled with Chrome and is documented as the default resolution for missing timeZone.
The chrome.timeZone API exists only on Chrome OS; it can change the system time zone but does not update already‑loaded web pages.
There is no public API, flag, or method to make an existing Intl.DateTimeFormat instance re‑query the OS time zone after a change.

Likely explanation for the inconsistency
The ECMAScript specification leaves the default time zone to the host environment, and Chrome does not expose a mapping from its locale‑preference list to the OS zone, so the result depends solely on the OS setting.
Steps to obtain an up‑to‑date zone

If you can change the OS time zone (via system settings or, on Chrome OS, the chrome.timeZone API), reload the page or create a new Intl.DateTimeFormat instance after the change.
On non‑Chrome OS platforms, only a page reload (or new instance) will reflect the updated OS zone.

Missing diagnostic detail
Are you targeting Chrome OS where the chrome.timeZone extension API is available, or another OS where only a reload works? Knowing this determines whether an extension‑based solution is feasible.

Intl.DateTimeFormat default time zone mapping: missing explicit mapping between Chrome locale preferences and OS time zone

Background

Current Constraints

Unresolved Decision

Questions

1 answer

Answer

Confirmed facts

Likely explanation for the inconsistency

Steps to obtain an up‑to‑date zone

Missing diagnostic detail

Your perspective belongs here.

0 question comments