diff --git a/spec/intl.html b/spec/intl.html index d0c64cd88..507278588 100644 --- a/spec/intl.html +++ b/spec/intl.html @@ -31,174 +31,6 @@
- Implementations that adopt this specification are time zone aware: they use the IANA Time Zone Database https://www.iana.org/time-zones/ to supply available 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. -
-- 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. -
-- To reduce disruption from renaming changes, ECMAScript implementations are encouraged to initially add the new Zone as a non-primary time zone identifier that resolves to the current primary identifier. - Then, after a waiting period, implementations are recommended to promote the new Zone to a primary time zone identifier while simultaneously demoting the deprecated name to non-primary. - The recommended waiting period is two years after the IANA Time Zone Database release containing the changes. - This delay allows other systems, that ECMAScript programs may interact with, to be updated to recognize the new Zone. -
-- 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 waiting period is necessary. -
-- If implementations revise time zone information during the lifetime of an agent, then which identifiers are supported, the primary time zone identifier associated with any identifier, and the UTC offsets and transitions associated with any Zone, must 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 available 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.
-
This definition supersedes the definition provided in
This specification identifies time zones using the Zone and Link names of the IANA Time Zone Database. Their canonical form is the corresponding Zone name in the casing used in the IANA Time Zone Database except as specifically overridden by CanonicalizeTimeZoneName.
- -A conforming implementation must recognize *"UTC"* and all other Zone and Link names (and only such names), and use best available current and historical information about their offsets from UTC and their daylight saving time rules in calculations. However, the set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent.
- -backward
of the IANA Time Zone Database.
- 1. If _ianaTimeZone_ is *"Etc/UTC"* or *"Etc/GMT"*, or *"GMT"*, return *"UTC"*.
- 1. Return _ianaTimeZone_.
- [...]
- -[...]
- -When the `supportedValuesOf` method is called with argument _key_ , the following steps are taken:
- -The *"length"* property of a DateTime format function is *1*𝔽.
This function provides access to the locale and options computed during initialization of the object.
- -For web compatibility reasons, if the property *"hourCycle"* is set, the *"hour12"* property should be set to *true* when *"hourCycle"* is *"h11"* or *"h12"*, or to *false* when *"hourCycle"* is *"h23"* or *"h24"*.
- -