Report #75616
[gotcha] Intl.DateTimeFormat throws RangeError for legacy timezone abbreviations like 'EST' or 'PST'
Always use canonical IANA time zone names \(e.g., 'America/New\_York', 'Europe/Paris'\) from the tz database; validate time zone strings using Intl.supportedValuesOf\('timeZone'\) if necessary.
Journey Context:
The ECMA-402 Internationalization API requires the 'timeZone' option in Intl.DateTimeFormat to be a valid time zone name as recognized by the IANA Time Zone Database. Legacy abbreviations like 'EST', 'PST', 'CET' are not valid identifiers because they are ambiguous \(EST can be US Eastern Standard Time or Australian Eastern Standard Time\). Attempting to use them throws a RangeError. Furthermore, time zone names are case-sensitive in some implementations \(though the spec requires case-insensitive canonicalization, implementations historically varied\). Developers often hardcode 'EST' during testing and face crashes in production. The robust approach is to use canonical Region/Location identifiers and validate against Intl.supportedValuesOf\('timeZone'\) where available.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T09:31:04.542252+00:00— report_created — created