Normative: Allow UTC offset time zones #788

gibson042 · 2023-06-01T15:18:10Z

Fixes #683

This aligns with ECMA-262, and therefore removes the DefaultTimeZone override.

Example time zones that will now be accepted: Temporal |TimeZoneUTCOffsetName|

"+00"
"-00"
"−00"
"+0000"
"-0000"
"−0000"
"+00:00"
"-00:00"
"−00:00"
"+2359"
"+23:59"
"-2359"
"-23:59"
"−2359"
"−23:59"

ptomato · 2023-06-01T15:57:23Z

spec/datetimeformat.html

+      <h1>FormatTimeZoneOffsetString ( _offsetNanoseconds_ )</h1>
+      <emu-alg>
+        1. Assert: _offsetNanoseconds_ is an integer.


I'd recommend a structured header (and then there's no need for the assertion). We can also limit the type of offsetNanoseconds to "an integer in the range of -86,400,000,000,000 to 86,400,000,000,000". (I forget whether the range is inclusive or exclusive at both ends.)

This operation is defined in Temporal and will be removed from ECMA-402 and/or this PR once added to ECMA-262. I will propagate any upstream changes.

justingrant

Looks great!

justingrant · 2023-06-01T17:21:39Z

spec/datetimeformat.html

-          1. If the result of IsValidTimeZoneName(_timeZone_) is *false*, then
-            1. Throw a *RangeError* exception.
+        1. If IsTimeZoneOffsetString(_timeZone_) is *true*, then
+          1. Let _offsetNanoseconds_ be ParseTimeZoneOffsetString(_timeZone_).


There's a new CanonicalizeTimeZoneOffsetString AO in Temporal. Should this be brought into 402 to replace this line and the one below it?

I tried to keep changes minimal here, but intend to make use of CanonicalizeTimeZoneOffsetString once it lands in ECMA-262.

I do not understand why not just change the definition of HourSubcomponents in ECMA262 instead
Currently, it is

HourSubcomponents[Extended] ::: TimeSeparator[?Extended] MinuteSecond TimeSeparator[?Extended] MinuteSecond TimeSeparator[?Extended] MinuteSecond TemporalDecimalFractionopt

why not change it to just

HourSubcomponents[Extended] ::: TimeSeparator[?Extended] MinuteSecond

?

The only place reference to it is UTCOffset and the only places refence to UTCOffset are
21.4.1.33.1 IsTimeZoneOffsetString ( offsetString )
and
21.4.1.33.2 ParseTimeZoneOffsetString ( offsetString )

which are exactly the two places we need to change and both places are only used by place dealing with system timezone.

@FrankYFTang An ECMA-262 grammar cannot be changed from an ECMA-402 pull request. But all of this will be simplified by/in response to Temporal, as demonstrated in #788 (comment) .

One thing I do not understand is why do we have this PR for ECMA402 instead of just let Temporal to change both ECMA262 and 402. What is the urgent need for that to happen before Temporal reach stage 4?

AFAIK, the main reason is that offset time zones are currently supported in (pre-Temporal) ECMA-262. My assumption is that all ECMA-262 features should be supported when ECMA-402 is also implemented.

Also, do we know yet whether ICU and/or CLDR changes will be needed to enable formatting of offset time zones? If no, that's great news. If yes, then where do changes need to be made?

FrankYFTang · 2023-06-01T18:25:04Z

Richard point out https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-08.html require nanoseconds in the TimeZone but I cannot see from that spec of such requirement.

what I see is

time-zone         = "[" critical-flag  
                        time-zone-name / time-numoffset "]"

date-time and time-numoffset are imported from Section 5.6 of [RFC3339]

   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]

so.... where is the nanosecond requirement?

gibson042 · 2023-06-01T22:48:33Z

so.... where is the nanosecond requirement?

It will be discussed upstream at tc39/ecma262#3087 and tc39/proposal-temporal#2593 .

sffc · 2023-06-02T00:28:44Z

TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-06-01.md#normative-allow-utc-offset-time-zones-788

We need to resolve the minutes/seconds/centiseconds/nanoseconds first, but it seems okay to the group besides that point, which was somewhat controversial for a number of reasons.

sffc · 2023-06-30T12:10:48Z

TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-06-29.md#normative-allow-utc-offset-timezones

We'd like to wait until the Temporal changes land and then revisit this PR after it has been updated.

gibson042 · 2023-07-12T23:19:35Z

@sffc Let's please also discuss it at the next TG2 meeting regardless.

FrankYFTang · 2023-07-13T00:37:27Z

@sffc Let's please also discuss it at the next TG2 meeting regardless.

added to https://github.com/tc39/ecma402/projects/2

sffc · 2023-09-07T18:45:21Z

Do we support formatting these with timeZoneName "shortOffset" and "longOffset"?

We should think about the formatting fallback given the six time zone format options: "short", "long", "shortOffset", "longOffset", "shortGeneric", "longGeneric". We discussed the fallback between these at length in the time zone format options proposal a couple of years ago. It shows up in BasicFormatMatcher: https://tc39.es/ecma402/#sec-basicformatmatcher

FrankYFTang · 2023-09-07T19:03:37Z

Please write some example of the timeZone which previous throw but after this PR will be accepted . Thanks

gibson042 · 2023-09-07T19:53:08Z

PR updated to remove support for UTC offsets with sub-minute precision, just like Temporal.

gibson042 · 2023-09-07T19:53:20Z

Please write some example of the timeZone which previous throw but after this PR will be accepted . Thanks

@FrankYFTang added to the PR description.

…ffset This aligns with ECMA-262, and therefore removes the DefaultTimeZone override.

Fixes tc39#683

sffc · 2023-09-07T20:40:42Z

TG2 approval pending additional review of the spec text: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-09-07.md#normative-allow-utc-offset-time-zones-788

FrankYFTang · 2023-09-08T20:56:07Z

spec/datetimeformat.html

+        1. If IsTimeZoneOffsetString(_timeZone_) is *true*, then
+          1. Let _parseResult_ be ParseText(StringToCodePoints(_timeZone_), |UTCOffset|).
+          1. Assert: _parseResult_ is a Parse Node.
+          1. If _parseResult_ contains more than one |MinuteSecond| Parse Node, throw a *RangeError* exception.


I am not sure how does "contains more than one |MinuteSecond| Parse Node" work here.
How is the "contains" operation defined for Parse Node? I cannot find a concrete definition.

Look at the UTCOffset grammar in https://tc39.es/ecma262/#sec-time-zone-offset-string-format

UTCOffset ::: TemporalSign Hour TemporalSign Hour HourSubcomponents[+Extended] TemporalSign Hour HourSubcomponents[~Extended]

So if the concept of "contains" is shallow, then it would be impossible for UTCOffset to contain any MinuteSecond.
since 1 or 2 MinuteSecond could be contain inside the HourSubcomponents that contained by UTCOffset. However, the require a "deep containment" interpretation and I am not sure that is what ECMA262 specify. (since I cannot find a clear definition of what "contains" mean for Parse Node.

@FrankYFTang This use of "contains" is prose of the sort that is also currently in Temporal ParseTimeZoneIdentifier—as suggested by the lack of automatic hyperlinking, there is no concrete definition. However, as I thought would be clear from context in both documents, it is intended to be understood as entailing deep inspection of the tree of Parse Nodes. Can you suggest a change here that would make that more clear?

I could define a precise syntax-directed operation, but really don't want to do that because it would apply cross-document to the ECMA-262 |UTCOffset| nonterminal that will be replaced by Temporal |TimeZoneUTCOffsetName| (creating a situation where this part of ECMA-402 would be incoherent until fixed).

It's also worth noting that this explicit check for multiple |MinuteSecond| Parse Nodes will itself be removed when Temporal lands, along with many of the other steps here that are subsumed by ParseTimeZoneIdentifier:

+ 1. Let _timeZoneRecord_ be ? ParseTimeZoneIdentifier(_timeZone_). - 1. If IsTimeZoneOffsetString(_timeZone_) is *true*, then - 1. Let _parseResult_ be ParseText(StringToCodePoints(_timeZone_), |UTCOffset|). - 1. Assert: _parseResult_ is a Parse Node. - 1. If _parseResult_ contains more than one |MinuteSecond| Parse Node, throw a *RangeError* exception. - 1. Let _offsetNanoseconds_ be ParseTimeZoneOffsetString(_timeZone_). - 1. Let _offsetMinutes_ be _offsetNanoseconds_ / (6 × 10<sup>10</sup>). - 1. Assert: _offsetMinutes_ is an integer. + 1. If _timeZoneRecord_.[[Name]] is ~empty~, then + 1. Let _offsetMinutes_ be _timeZoneRecord_.[[OffsetMinutes]]. 1. Set _timeZone_ to FormatOffsetTimeZoneIdentifier(_offsetMinutes_). - 1. Else if IsValidTimeZoneName(_timeZone_) is *true*, then - 1. Set _timeZone_ to CanonicalizeTimeZoneName(_timeZone_). + 1. Else if IsValidTimeZoneName(_timeZoneRecord_.[[Name]]) is *true*, then + 1. Set _timeZone_ to CanonicalizeTimeZoneName(_timeZoneRecord_.[[Name]]). 1. Else, 1. Throw a *RangeError* exception.

FrankYFTang · 2023-09-09T07:23:03Z

sorry, I click the wrong bottom.

FrankYFTang · 2023-09-09T09:18:43Z

Trying to implement in v8 https://chromium-review.googlesource.com/c/v8/v8/+/4854730

FrankYFTang · 2023-09-12T01:29:51Z

ICU SimpleTimeZone created by TimeZone::createInstance will handle the offset timezone but use id prefix with "GMT"
so it will be "GMT+01:30" or "GMT-05:33" etc. My v8 implementation just check if it is starting with "GMT" and then remove that "GMT" prefix

FrankYFTang · 2023-09-12T03:02:38Z

One problem we have with the implementation is we can take the input timezone as
"+00"
"-00"
"−00"
"+0000"
"-0000"
"−0000"
"+00:00"
"-00:00"
"−00:00"

but we it will be inefficient to distinguish it from "UTC" from the resolvedOptions. Could we treat them as simply as "UTC" in the spec text? (so resolvedOptions().timeZone will return "UTC" for these cases.

tc39/ecma402#788

FrankYFTang · 2023-09-12T04:23:34Z

please take a look at tc39/test262#3917
At first I have some concern about the following name

"+00"
"-00"
"−00"
"+0000"
"-0000"
"−0000"
"+00:00"
"-00:00"
"−00:00"

But after I dig into it more I think the current PR will make them all become timeZone "+00:00" and that should be fine.

spec/datetimeformat.html

FrankYFTang · 2023-09-12T20:46:11Z

My understanding is for the following code

(new Intl.DateTimeFormat(undefined, {timeZone}).resolvedOptions().timeZone

should get the following result:
"+00" => "+00:00"
"-00" => "+00:00"
"−00" => "+00:00"
"+0000" => "+00:00"
"-0000" => "+00:00"
"−0000" => "+00:00"
"+00:00" => "+00:00"
"-00:00" => "+00:00"
"−00:00" => "+00:00"
"+2359" => "+23:59"
"+23:59" => "+23:59"
"-2359" => "-23:59"
"-23:59" => "-23:59"
"−2359" => "-23:59"
"−23:59" => "-23:59"

Please comment if my understanding is incorrect. thanks

justingrant · 2023-09-12T22:48:23Z

"-00" => "-00:00"

Nope. -00, -00:00, -0000, +00, and +0000 should all be normalized to +00:00. Here's why:

String IDs of built-in time zones (either offset or IANA) that are returned by ECMAScript methods (including getters) should always be normalized. For offset zones, normalized means ±HH:MM, with -00:00 not allowed. For IANA time zones, normalized means matching the letter case used in the IANA time zone database. ECMAScript methods should accept non-normalized formats like +00 or -00:00, but should never return a time zone ID string except in a normalized format.

This normalization behavior is specified in https://tc39.es/proposal-temporal/#sec-time-zone-identifiers, as well as in AO spec text in both Temporal and this PR. (If you find a case where an ECMAScript method is allowed to return a non-normalized ID for a built-in offset time zone or built-in named time zone, then it's a spec bug.)

The reason why we require normalized outputs is so that implementations won't have to store the original ID strings that users provided. Instead, implementations are free to store timezone ID slots in a more optimized way, as long as the normalized ID string can be reconstituted later as needed. (e.g. in id or timeZoneId getters).

For example, an implementation could optimize storage of a timezone ID slot using a 16-bit union:

one bit to mark the ID as an offset time zone ID or IANA ID
if offset, a 12-bit signed number of minutes (from -1439 representing -23:59 to +1439 representing +23:59)
if IANA, a 10-bit unsigned index into a cached array of the ~600 IANA ID strings

Hopefully this explains why "-00" => "+00:00" is the expected behavior.

justingrant · 2023-09-13T02:00:48Z

it will be inefficient to distinguish it from "UTC" from the resolvedOptions. Could we treat them as simply as "UTC" in the spec text? (so resolvedOptions().timeZone will return "UTC" for these cases.

I assume that we want new Intl.DateTimeFormat('en', {timeZone}).resolvedOptions().tineZone to always match Temporal.TimeZone.from(timeZone).id. Making them different would be confusing for users. Assuming they should behave the same, then:

Normalizing the offset time zone ID "+00:00" into the IANA time zone ID "UTC" would be a normative change to Temporal and I'm pretty sure also a normative change to pre-Temporal ECMA-262. Without digging into the specs it's hard to know how much churn this change would cause, but the bar for normative changes like this is very high so the default should be to avoid making changes like this.
There's also a user-facing advantage of leaving them separate, because UTC and +00:00 do have a slight semantic difference. UTC has a special meaning as a "computers-only" time zone; no humans are in a place where "UTC" is their time zone ID. On the other hand, +00:00 is interpreted to mean an offshore time zone where humans are, like a boat 500km south of Liberia. So even though those two zones return identical results, it can be helpful for a userland app to know the difference. For example, an app may choose to show a user a warning message, e.g. "No humans live in a place whose time zone ID is 'UTC'. Was this a mistake?".

So unless there's a very large performance advantage of making this change, then I'd like to leave the current spec as-is so that +00:00 and UTC are treated as distinct time zones, even though they always result in the same numeric results.

FrankYFTang · 2023-09-13T03:39:28Z

I drop my early concern about "+00:00" vs "UTC". It is not a problem.

Louis-Aime · 2023-09-14T20:29:06Z

I understand this PR is about letting an author specify a time zone with a simple string, as an offset to UTC, in the context of Temporal. I withdraw the concern I had during last meeting. Temporal.TimeZone has all functions for the use cases I had in mind.

However we should then stick to the documentation for timeZone.getOffsetString():

This method is similar to timeZone.getOffsetNanosecondsFor(), but returns the offset formatted as a string, with sign, hours, and minutes.

The present polyfill gives also the seconds:
mytz = new Temporal.TimeZone('Europe/Paris');
mytz.getOffsetStringFor('1900-02-01T12:00Z'); // '00:09:21'

justingrant · 2023-09-14T22:02:28Z

I understand this PR is about letting an author specify a time zone with a simple string, as an offset to UTC, in the context of Temporal. I withdraw the concern I had during last meeting. Temporal.TimeZone has all functions for the use cases I had in mind.

However we should then stick to the documentation for timeZone.getOffsetString():

This method is similar to timeZone.getOffsetNanosecondsFor(), but returns the offset formatted as a string, with sign, hours, and minutes.

The present polyfill gives also the seconds: mytz = new Temporal.TimeZone('Europe/Paris'); mytz.getOffsetStringFor('1900-02-01T12:00Z'); // '00:09:21'

The documentation is wrong. If a built-in IANA time zone (or a custom time zone that inherits from a built-in IANA zone) has sub-minute offsets, then TimeZone.p.getOffsetStringFor and ZonedDateTime.p.offset should return the string including sub-minute values. The limitation to minutes precision applies only to offset time zones, not to IANA zones.

I'm working on a PR (EDIT: tc39/proposal-temporal#2674) of those docs to fix the problem.

FrankYFTang · 2023-09-26T02:42:16Z

This PR reach consensus on 2023-09-26 meeting

ryzokuken · 2023-09-26T14:07:12Z

Is this still blocked on something or should I hit merge?

tc39/ecma402#788

* Add test for ECMA402 PR 788 tc39/ecma402#788 * Fix misunderstanding about "+00:00" * Fix lint * Swap actual, expected position * Update test/intl402/DateTimeFormat/prototype/resolvedOptions/offset-timezone-change.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/prototype/resolvedOptions/offset-timezone-basic.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/prototype/formatToParts/offset-timezone-correct.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/constructor-invalid-offset-timezone.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/constructor-invalid-offset-timezone.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/prototype/resolvedOptions/offset-timezone-change.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/constructor-invalid-offset-timezone.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/prototype/format/offset-timezone-gmt-same.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/prototype/format/offset-timezone-gmt-same.js Co-authored-by: Richard Gibson <[email protected]> * Update test/intl402/DateTimeFormat/prototype/formatToParts/offset-timezone-correct.js Co-authored-by: Richard Gibson <[email protected]> --------- Co-authored-by: Richard Gibson <[email protected]>

FrankYFTang · 2023-09-26T21:54:19Z

please merge

justingrant · 2023-09-27T04:54:40Z

Congratulations everyone for getting this over the finish line!

gibson042 requested review from sffc and ryzokuken June 1, 2023 15:18

This was referenced Jun 1, 2023

ECMA-402 should allow numeric-offset host time zones #683

Closed

Editorial: Fix up minor issues in FormatTimeZoneOffsetString tc39/proposal-temporal#2592

Merged

ptomato reviewed Jun 1, 2023

View reviewed changes

ryzokuken added the normative label Jun 1, 2023

justingrant approved these changes Jun 1, 2023

View reviewed changes

This was referenced Jun 1, 2023

Normative: Limit time zone offset precision to minutes tc39/ecma262#3087

Open

Maximum precision of offset time zones tc39/proposal-temporal#2593

Closed

justingrant mentioned this pull request Jun 30, 2023

FrankYFTang's feedback about the current spec text tc39/proposal-canonical-tz#39

Closed

ryzokuken approved these changes Sep 7, 2023

View reviewed changes

gibson042 added 3 commits September 7, 2023 15:55

Normative: Allow implementations to report their time zone as a UTC o…

dad8765

…ffset This aligns with ECMA-262, and therefore removes the DefaultTimeZone override.

Normative: Allow ECMAScript code to specify UTC offset time zones

c3517cd

Fixes tc39#683

Normative: Drop support for sub-minute UTC offsets

26ba452

gibson042 force-pushed the gh-683-offset-time-zones branch from 673ca2e to 26ba452 Compare September 7, 2023 19:55

sffc approved these changes Sep 7, 2023

View reviewed changes

FrankYFTang reviewed Sep 8, 2023

View reviewed changes

This comment was marked as off-topic.

Sign in to view

FrankYFTang closed this Sep 9, 2023

FrankYFTang reopened this Sep 9, 2023

This comment was marked as off-topic.

Sign in to view

FrankYFTang added a commit to FrankYFTang/test262 that referenced this pull request Sep 12, 2023

Add test for ECMA402 PR 788

9998c6c

tc39/ecma402#788

FrankYFTang mentioned this pull request Sep 12, 2023

Add test for ECMA402 PR 788 tc39/test262#3917

Merged

FrankYFTang reviewed Sep 12, 2023

View reviewed changes

spec/datetimeformat.html Show resolved Hide resolved

ryzokuken added has consensus (TG1) Has consensus from TC39-TG1 has consensus Has consensus from TC39-TG2 labels Sep 26, 2023

ptomato pushed a commit to FrankYFTang/test262 that referenced this pull request Sep 26, 2023

Add test for ECMA402 PR 788

810011d

tc39/ecma402#788

ryzokuken merged commit e25c455 into tc39:master Sep 27, 2023
4 checks passed

gibson042 mentioned this pull request Sep 28, 2023

Editorial: Modernise spec to use structured headers and correct number representations #822

Merged

FrankYFTang mentioned this pull request Oct 2, 2023

ICU-22526 Allow GMT-23:59 time zone unicode-org/icu#2646

Merged

7 tasks

ben-allen mentioned this pull request Apr 30, 2024

Updated Intl.DateTimeFormat's timeZone parameter description to reflect current requirements for conforming ECMA-402 implementations" mdn/content#33341

Merged

Normative: Allow UTC offset time zones #788

Normative: Allow UTC offset time zones #788

Conversation

gibson042 commented Jun 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

justingrant left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FrankYFTang Sep 8, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FrankYFTang commented Jun 1, 2023 • edited Loading

gibson042 commented Jun 1, 2023

sffc commented Jun 2, 2023

sffc commented Jun 30, 2023

gibson042 commented Jul 12, 2023

FrankYFTang commented Jul 13, 2023

sffc commented Sep 7, 2023

FrankYFTang commented Sep 7, 2023

gibson042 commented Sep 7, 2023

gibson042 commented Sep 7, 2023

sffc commented Sep 7, 2023

FrankYFTang Sep 8, 2023 • edited Loading

Choose a reason for hiding this comment

gibson042 Sep 8, 2023 • edited Loading

Choose a reason for hiding this comment

This comment was marked as off-topic.

FrankYFTang commented Sep 9, 2023

FrankYFTang commented Sep 9, 2023

This comment was marked as off-topic.

FrankYFTang commented Sep 12, 2023

FrankYFTang commented Sep 12, 2023

FrankYFTang commented Sep 12, 2023 • edited Loading

FrankYFTang commented Sep 12, 2023 • edited Loading

justingrant commented Sep 12, 2023 • edited Loading

justingrant commented Sep 13, 2023

FrankYFTang commented Sep 13, 2023

Louis-Aime commented Sep 14, 2023 • edited Loading

justingrant commented Sep 14, 2023 • edited Loading

FrankYFTang commented Sep 26, 2023

ryzokuken commented Sep 26, 2023

FrankYFTang commented Sep 26, 2023

justingrant commented Sep 27, 2023

gibson042 commented Jun 1, 2023 •

edited

Loading

FrankYFTang Sep 8, 2023 •

edited

Loading

FrankYFTang commented Jun 1, 2023 •

edited

Loading

FrankYFTang Sep 8, 2023 •

edited

Loading

gibson042 Sep 8, 2023 •

edited

Loading

FrankYFTang commented Sep 12, 2023 •

edited

Loading

FrankYFTang commented Sep 12, 2023 •

edited

Loading

justingrant commented Sep 12, 2023 •

edited

Loading

Louis-Aime commented Sep 14, 2023 •

edited

Loading

justingrant commented Sep 14, 2023 •

edited

Loading