Intl.DateTimeFormat default time zone mapping: missing explicit mapping between Chrome locale preferences and OS time zone
0 reputation · 18 Oct 2020, 12:39 UTC
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?
chrome