Implementations that adopt this specification must be time zone aware: they must use the IANA Time Zone Database https://www.iana.org/time-zones/ to supply time zone identifiers and data used in ECMAScript calculations and formatting. This section defines how the IANA Time Zone Database should be used by time zone aware implementations. -
-- Except as overridden by AvailableNamedTimeZoneIdentifiers, each Zone in the IANA Time Zone Database must be a primary time zone identifier and each Link name in the IANA Time Zone Database must be a non-primary time zone identifier. No String may be an available named time zone identifier unless it is a Zone name or a Link name in the IANA Time Zone Database. Available named time zone identifiers returned by ECMAScript built-in objects must use the casing found in the IANA Time Zone Database.
- In the IANA Time Zone Database, the UTC time zone is represented by the Zone *"Etc/UTC"* which is distinct from the Zone *"Etc/GMT"*. - For historical reasons, ECMAScript uses *"UTC"* as the primary identifier for the former Zone and does not recognize the latter Zone as distinct, instead requiring *"Etc/UTC"*, *"Etc/GMT"*, and *"GMT"* (if available) to be non-primary identifiers that resolve to *"UTC"*. - This is the only deviation from the IANA Time Zone Database that is required of a time zone aware ECMAScript implementation. + Each Zone in the IANA Time Zone Database must be a primary time zone identifier and each Link name in the IANA Time Zone Database must be a non-primary time zone identifier that resolves to its corresponding Zone name, with the following exceptions implemented in AvailableNamedTimeZoneIdentifiers:
+| Primary Time Zone Identifier | +|
|---|---|
| *"EST"* | +*"Etc/GMT+5"* | +
| *"MST"* | +*"Etc/GMT+7"* | +
| *"HST"* | +*"Etc/GMT+10"* | +
| *"EST5EDT"* | +*"America/New_York"* | +
| *"CST6CDT"* | +*"America/Chicago"* | +
| *"MST7MDT"* | +*"America/Denver"* | +
| *"PST8PDT"* | +*"America/Los_Angeles"* | +
| *"WET"* | +*"Europe/Lisbon"* | +
| *"CET"* | +*"Europe/Berlin"* | +
| *"MET"* | +*"Europe/Vienna"* | +
| *"EET"* | +*"Europe/Athens"* | +
+ The IANA Time Zone Database offers build options that affect which time zone identifiers are primary. + The default build options merge different countries' time zones, for example *"Atlantic/Reykjavik"* is built as a Link to the Zone *"Africa/Abidjan"*. + Geographically and politically distinct locations are likely to introduce divergent time zone rules in a future version of the IANA Time Zone Database. + The exceptions above serve to mitigate these future-compatibility issues for ECMAScript programmers and end users. +
+
+ International Components for Unicode (ICU) https://icu.unicode.org/ is a widely-used library that exposes IANA Time Zone Database information.
+ ICU implements most of the exceptions above when determining which available named time zone identifiers are primary or non-primary.
+ Although use of ICU is recommended for consistency between implementations, it is not required.
+ Non-ICU-based implementations can still use ICU's identifier data, as found in *timezone.xml* in the Unicode Common Locale Data Repository (CLDR) https://cldr.unicode.org/.
+ Implementations may also build the IANA Time Zone Database directly, for example by using build options such as PACKRATDATA=backzone PACKRATLIST=zone.tab and performing any post-processing needed to ensure compliance with the requirements above.
+
The IANA Time Zone Database is typically updated between five and ten times per year. These updates may add new Zone or Link names, may change Zones to Links, and may change the UTC offsets and transitions associated with any Zone. ECMAScript implementations are recommended to include updates to the IANA Time Zone Database as soon as possible. Such prompt action ensures that ECMAScript programs can accurately perform time-zone-sensitive calculations and can use newly-added available named time zone identifiers supplied by external input or the host environment.
++ Although the IANA Time Zone Database maintainers strive for stability, in rare cases (averaging less than once per year) a Zone may be replaced by a new Zone. + For example, in 2022 "*Europe/Kiev*" was deprecated to a Link resolving to a new "*Europe/Kyiv*" Zone. + The deprecated Link is called a renamed time zone identifier and the newly-added Zone is called a replacement time zone identifier. +
++ To reduce disruption from these infrequent changes, ECMAScript implementations must initially add each replacement time zone identifier as a non-primary time zone identifier that resolves to the existing renamed time zone identifier. + This allows ECMAScript programs to recognize both identifiers, but also reduces the chance that an ECMAScript program will send the replacement time zone identifier to another system that does not yet recognize it. + After a waiting period, implementations must promote the new Zone to a primary time zone identifier while simultaneously demoting the renamed time zone identifier to non-primary. + This waiting period is two years after the IANA Time Zone Database release containing the changes, to provide ample time for other systems to be updated. + After two years, implementations should update their time zone data to make the replacement time zone identifier primary and the renamed time zone identifier non-primary. + This two-year period does not need to be exact. + For example, it's acceptable to wait until the next ICU release after two years has expired. +
++ A waiting period should only apply when a new Zone is added to replace an existing Zone. + If an existing Zone and Link are swapped, then no renaming has happened and no waiting period is necessary. +
- If implementations revise time zone information during the lifetime of an agent, then it is recommended that the list of available named time zone identifiers, the primary time zone identifier associated with any available named time zone identifier, and the UTC offsets and transitions associated with any available named time zone identifier, be consistent with results previously observed by that agent. - Due to the complexity of supporting this recommendation, it is recommended that implementations maintain a fully consistent copy of the IANA Time Zone Database for the lifetime of each agent. + If implementations revise time zone information during the lifetime of an agent, then it is required that the list of available named time zone identifiers, the primary time zone identifier associated with any available named time zone identifier, and the UTC offsets and transitions associated with any available named time zone identifier, be consistent with results previously observed by that agent. + Due to the complexity of supporting this requirement, it is recommended that implementations maintain a fully consistent copy of the IANA Time Zone Database for the lifetime of each agent.
This section complements but does not supersede
- The IANA Time Zone Database offers build options that affect which time zone identifiers are primary.
- The default build options merge different countries' time zones, for example *"Atlantic/Reykjavik"* being a Link to the Zone *"Africa/Abidjan"*.
- Geographically and politically distinct locations are likely to introduce divergent time zone rules in a future version of the IANA Time Zone Database.
- Therefore, it is recommended that ECMAScript implementations instead use build options such as PACKRATDATA=backzone PACKRATLIST=zone.tab or a similar alternative that ensures at least one primary identifier for each ISO 3166-1 Alpha-2 country code.
-