Skip to content

Commit

Permalink
Rebase spec text to 262
Browse files Browse the repository at this point in the history
Align spec text to tc39/ecma262#3035, which is
the editorial PR that this proposal is stacked on top of.
  • Loading branch information
justingrant committed Jun 4, 2023
1 parent 4ec899c commit 069a9f5
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 15 deletions.
20 changes: 10 additions & 10 deletions spec/intl.html
Original file line number Diff line number Diff line change
Expand Up @@ -32,16 +32,16 @@ <h1>Time Zone Identifiers</h1>
</p>

<ins class="block">
<p>
Although the IANA Time Zone Database maintainers strive for stability, in rare cases identifiers will be renamed.
For example, the IANA Time Zone Database's 2022b release added "*Europe/Kyiv*" as a new Zone and demoted "*Europe/Kiev*" to be a Link to the new Zone.
To reduce disruption from these renaming changes, ECMAScript implementations are encouraged to initially add the new name as a non-primary time zone identifier that resolves to the old 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 (TODO: may change) after the IANA Time Zone Database release containing the changes.
This is long enough to allow most other systems that ECMAScript programs may interact with to "catch up" with the change so that the new zone is recognized.
Note that this waiting period should only apply to cases where an existing Zone is replaced by a new Zone name.
If an existing Zone and Link are swapped, then no waiting period is recommended.
</p>
<p>
Although the IANA Time Zone Database maintainers strive for stability, in rare cases identifiers will be renamed.
For example, the IANA Time Zone Database's 2022b release added "*Europe/Kyiv*" as a new Zone and demoted "*Europe/Kiev*" to be a Link to the new Zone.
To reduce disruption from these renaming changes, ECMAScript implementations are encouraged to initially add the new name as a non-primary time zone identifier that resolves to the old 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 (TODO: may change) after the IANA Time Zone Database release containing the changes.
This is long enough to allow most other systems that ECMAScript programs may interact with to "catch up" with the change so that the new zone is recognized.
Note that this waiting period should only apply to cases where an existing Zone is replaced by a new Zone name.
If an existing Zone and Link are swapped, then no waiting period is recommended.
</p>
</ins>

<p>
Expand Down
10 changes: 5 additions & 5 deletions spec/timezone.html
Original file line number Diff line number Diff line change
Expand Up @@ -20,24 +20,24 @@ <h1>SystemTimeZoneIdentifier ( ): a String</h1>
<dl class="header">
<dt>description</dt>
<dd>
It returns a String value representing the environment's current time zone, which is either a String representing a UTC offset for which IsTimeZoneOffsetString returns *true*, or a primary time zone identifier.
It returns a String representing the host environment's current time zone, which is either a String representing a UTC offset for which IsTimeZoneOffsetString returns *true*, or a primary time zone identifier.
</dd>
</dl>

<emu-alg>
1. If the implementation only supports the UTC time zone, return *"UTC"*.
1. Let _systemTimeZoneString_ be the String representing the environment's current time zone, either a named time zone identifier or a UTC offset string.
1. Let _systemTimeZoneString_ be the String representing the host environment's current time zone, either a named time zone identifier or a UTC offset string.
1. If IsTimeZoneOffsetString(_systemTimeZoneString_) is *true*, return <del>_systemTimeZoneString_</del><ins>CanonicalizeTimeZoneOffsetString(_systemTimeZoneString_)</ins>.
1. Assert: _systemTimeZoneString_ is equal to the [[PrimaryIdentifier]] property of at least one Time Zone Identifier Record returned by AvailableNamedTimeZoneIdentifiers().
1. Assert: _systemTimeZoneString_ is the value of the [[PrimaryIdentifier]] field of at least one Time Zone Identifier Record returned by AvailableNamedTimeZoneIdentifiers().
1. Return _systemTimeZoneString_.
</emu-alg>

<emu-note>
<p>
To ensure the level of functionality that implementations commonly provide in the methods of the Date object, it is recommended that SystemTimeZoneIdentifier return an IANA time zone name corresponding to the environment's time zone setting, if such a thing exists.
To ensure the level of functionality that implementations commonly provide in the methods of the Date object, it is recommended that SystemTimeZoneIdentifier return an IANA time zone name corresponding to the host environment's time zone setting, if such a thing exists.
GetNamedTimeZoneEpochNanoseconds and GetNamedTimeZoneOffsetNanoseconds must reflect the local political rules for standard time and daylight saving time in that time zone, if such rules exist.
</p>
<p>For example, if the environment is a browser on a system where the user has chosen US Eastern Time as their time zone, SystemTimeZoneIdentifier returns *"America/New_York"*.</p>
<p>For example, if the host environment is a browser on a system where the user has chosen US Eastern Time as their time zone, SystemTimeZoneIdentifier returns *"America/New_York"*.</p>
</emu-note>
</emu-clause>

Expand Down

0 comments on commit 069a9f5

Please sign in to comment.