Normative: Clarify validity of negative expanded year 0. #2550

EricIO · 2021-10-10T19:28:15Z

Following a discussion in
tc39/proposal-temporal#1753 there is some
reason to clarify the parsing of a negative expanded year 0 (-000000).

There is currently some discrepancy in how different implementors
parse this, some rejecting and some accepting a negative expanded year
0.

ljharb · 2021-10-10T20:46:02Z

Can you provide more details about current web reality here?

A normative change requires consensus, which includes the implementers who’d need to change being willing to do so, so we need to be clear about who those are and what needs changing.

EricIO · 2021-10-10T21:53:03Z

Date.parse("-000000-01-01T00:00:00.000Z")

SpiderMonkey: -62167219200000
JSC: -62167219200000
V8: NaN

ljharb · 2021-10-11T00:15:07Z

It’d be great to run https://npmjs.com/eshost and get data for all the engines :-) but that’s a great start

arhadthedev · 2021-10-11T07:37:25Z

@ljharb, here are the results for eshost -se 'Date.parse("-000000-01-01T00:00:00.000Z")':

#### ChakraCore, engine262, V8
NaN

#### GraalJS, JavaScriptCore, Moddable XS, QuickJS, SpiderMonkey
-62167219200000

Details on engines for reproducibility:

┌────────────────┬───────────┬────────────────────────────────────────────┬──────┬────────────────────────────────────────────────┐
│ name           │ type      │ path                                       │ args │ tags                                           │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ ChakraCore     │ ch        │ /home/runner/.esvu/bin/chakra              │      │ 1_11_24,web                                    │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ GraalJS        │ graaljs   │ /home/runner/.esvu/bin/graaljs             │      │ 21.2.0                                         │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ JavaScriptCore │ jsc       │ /home/runner/.esvu/bin/jsc                 │      │ 283881,web                                     │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ Moddable XS    │ xs        │ /home/runner/.esvu/bin/xs                  │      │ 10.5.0,embedded                                │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ QuickJS        │ qjs       │ /home/runner/.esvu/bin/quickjs-run-test262 │      │ 2021-03-27,embedded                            │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ SpiderMonkey   │ jsshell   │ /home/runner/.esvu/bin/sm                  │      │ 95.0a1#20211010214947,web                      │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ V8             │ d8        │ /home/runner/.esvu/bin/v8                  │      │ 9.7.3,web                                      │
├────────────────┼───────────┼────────────────────────────────────────────┼──────┼────────────────────────────────────────────────┤
│ engine262      │ engine262 │ /home/runner/.esvu/bin/engine262           │      │ 0.0.1-f47d7da0653c7b2f0417395794a5259c2287cc44 │
└────────────────┴───────────┴────────────────────────────────────────────┴──────┴────────────────────────────────────────────────┘

It’d be great to run https://npmjs.com/eshost

Unfortunately, a newcomer will install a library and will stuck, so I'd rather refer to https://npmjs.com/eshost-cli (plus https://npmjs.com/esvu to properly install engines and feed them to eshost).

ljharb · 2021-10-11T18:09:21Z

Thanks, I've added this to the next meeting's agenda.

gibson042 · 2021-10-25T04:38:48Z

ISO 8601-1:2019 §3.2.4 documents use of ± for "a plus sign [“+”] to represent a positive value or zero (the plus sign shall not be omitted), or a minus sign [“-”] otherwise" and employs that in describing expanded representations as in "[±][year(i)…". ISO 8601-2:2019 §4.4.1.2 makes it even more clear, extending part 1 to allow "negative values for years prior to year zero (0)". Further, ECMA-262 itself already defines "The year 0 is considered positive and hence prefixed with a + sign." Unless there's specific reason to support "-000000", I don't think it should be allowed.

EricIO · 2021-10-25T05:44:15Z

I'm happy with both outcomes, I think the main issue is that whatever we choose should be clarified in the text given the current divergence/confusion amongst the different implementations (given that this all started with a patch to firefox I submitted to disallow "-000000" it would indeed be nice to not "waste" that work :) )

ljharb · 2021-10-25T12:16:28Z

For Temporal, the committee provided consensus today to disallow negative year zeros.

For Date.parse, let's update this PR to clarify the prose that it is disallowed, and then hopefully we can hear from folks from the relevant engines on the thread affirming that the change is acceptable; and we can seek consensus in plenary for that final change once ready.

EricIO · 2021-11-07T21:58:41Z

Sorry for the silence. Here is an updated version that clarifies the text in the expanded year section to disallow -000000.

michaelficarra · 2021-11-09T17:59:58Z

spec.html

@@ -32067,7 +32067,7 @@ <h1>Date Time String Format</h1>

        <emu-clause id="sec-expanded-years" oldids="sec-extended-years">
          <h1>Expanded Years</h1>
-          <p>Covering the full time value range of approximately 273,790 years forward or backward from 1 January 1970 (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>) requires representing years before 0 or after 9999. ISO 8601 permits expansion of the year representation, but only by mutual agreement of the partners in information interchange. In the simplified ECMAScript format, such an expanded year representation shall have 6 digits and is always prefixed with a + or - sign. The year 0 is considered positive and hence prefixed with a + sign. Strings matching the <emu-xref href="#sec-date-time-string-format">Date Time String Format</emu-xref> with expanded years representing instants in time outside the range of a time value are treated as unrecognizable by <emu-xref href="#sec-date.parse">`Date.parse`</emu-xref> and cause that function to return *NaN* without falling back to implementation-specific behaviour or heuristics.</p>
+          <p>Covering the full time value range of approximately 273,790 years forward or backward from 1 January 1970 (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>) requires representing years before 0 or after 9999. ISO 8601 permits expansion of the year representation, but only by mutual agreement of the partners in information interchange. In the simplified ECMAScript format, such an expanded year representation shall have 6 digits and is always prefixed with a + or - sign. The year 0 is considered positive and must be prefixed with a + sign, 0 prefixed with a - sign must be rejected. Strings matching the <emu-xref href="#sec-date-time-string-format">Date Time String Format</emu-xref> with expanded years representing instants in time outside the range of a time value are treated as unrecognizable by <emu-xref href="#sec-date.parse">`Date.parse`</emu-xref> and cause that function to return *NaN* without falling back to implementation-specific behaviour or heuristics.</p>


Suggested change

<p>Covering the full time value range of approximately 273,790 years forward or backward from 1 January 1970 (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>) requires representing years before 0 or after 9999. ISO 8601 permits expansion of the year representation, but only by mutual agreement of the partners in information interchange. In the simplified ECMAScript format, such an expanded year representation shall have 6 digits and is always prefixed with a + or - sign. The year 0 is considered positive and must be prefixed with a + sign, 0 prefixed with a - sign must be rejected. Strings matching the <emu-xref href="#sec-date-time-string-format">Date Time String Format</emu-xref> with expanded years representing instants in time outside the range of a time value are treated as unrecognizable by <emu-xref href="#sec-date.parse">`Date.parse`</emu-xref> and cause that function to return *NaN* without falling back to implementation-specific behaviour or heuristics.</p>

<p>Covering the full time value range of approximately 273,790 years forward or backward from 1 January 1970 (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>) requires representing years before 0 or after 9999. ISO 8601 permits expansion of the year representation, but only by mutual agreement of the partners in information interchange. In the simplified ECMAScript format, such an expanded year representation shall have 6 digits and is always prefixed with a + or - sign. The year 0 is considered positive and must be prefixed with a + sign. The representation of the year 0 as -000000 is invalid. Strings matching the <emu-xref href="#sec-date-time-string-format">Date Time String Format</emu-xref> with expanded years representing instants in time outside the range of a time value are treated as unrecognizable by <emu-xref href="#sec-date.parse">`Date.parse`</emu-xref> and cause that function to return *NaN* without falling back to implementation-specific behaviour or heuristics.</p>

Two sentences. Also clarified.

Github won't allow me to commit this suggestion. Perhaps someone with write permission must do it? Seems like a better wording to me so I'd be happy with it.

Github won't allow me to commit this suggestion.

If you mean via the "Commit suggestion" button, yeah that's never worked.

I believe it doesn't work when the suggestion is left by someone with write access. You can add it on the command line tho.

Following a discussion in tc39/proposal-temporal#1753 there is some reason to clarify the parsing of a negative expanded year 0 (-000000). There is currently some discreprancy in how different implementors parse this, some rejecting and some accepting a negative expanded year 0.

ljharb · 2022-03-09T22:19:36Z

@ptomato ping for getting this on your radar; is someone working on test262 tests for this change, so we can land this normative PR?

ptomato · 2022-03-09T23:15:14Z

Test262 tests for the Temporal part of it have already landed: tc39/test262@4596c7e

I assumed someone else was going to do the legacy Date part of it... it should be more straightforward than for Temporal, since IIUC only two entry points have to be covered. I can do it eventually, but I have to concentrate on Temporal stuff until the March plenary.

ljharb · 2022-03-09T23:29:27Z

I believe this PR can't land until those tests are done; it's fine if it needs to wait until after March, it'll just miss the ES2022 train.

ptomato · 2022-04-09T00:13:22Z

This now has tests at tc39/test262#3470

https://bugs.webkit.org/show_bug.cgi?id=240263 Reviewed by Yusuke Suzuki. As of the following two PRs, -000000 is officially disallowed as a representation of the year zero in ISO date strings. tc39/ecma262#2550 tc39/proposal-temporal#1992 This patch implements the change for Temporal and Date alike. * test262/expectations.yaml: Mark 24 test cases as passing. * runtime/ISO8601.cpp: (JSC::ISO8601::parseDate): * wtf/DateMath.cpp: (WTF::parseES5DatePortion): Canonical link: https://commits.webkit.org/250432@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@293996 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Following a discussion in tc39/proposal-temporal#1753 there is some reason to clarify the parsing of a negative expanded year 0 (-000000). There is currently some discreprancy in how different implementors parse this, some rejecting and some accepting a negative expanded year 0.

ljharb · 2022-08-03T22:16:03Z

@EricIO would you mind signing the IPR form? Thanks!

EricIO · 2022-08-04T18:28:20Z

@EricIO would you mind signing the IPR form? Thanks!

@ljharb Done!

ljharb added needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 web reality and removed needs data This PR needs more information; such as web compatibility data, “web reality” (what all engines do)… labels Oct 11, 2021

ljharb mentioned this pull request Oct 25, 2021

Is "-000000" a valid extended year format? tc39/proposal-temporal#1753

Closed

EricIO force-pushed the master branch from 87a0ad3 to b4b74ab Compare November 7, 2021 21:57

ljharb added the needs data This PR needs more information; such as web compatibility data, “web reality” (what all engines do)… label Nov 7, 2021

gibson042 approved these changes Nov 8, 2021

View reviewed changes

michaelficarra reviewed Nov 9, 2021

View reviewed changes

EricIO force-pushed the master branch from b4b74ab to ca95f7a Compare November 11, 2021 21:19

ljharb force-pushed the master branch from ca95f7a to aff5c97 Compare November 18, 2021 07:07

ljharb added has consensus This has committee consensus. and removed needs consensus This needs committee consensus before it can be eligible to be merged. needs data This PR needs more information; such as web compatibility data, “web reality” (what all engines do)… labels Nov 18, 2021

ptomato mentioned this pull request Apr 9, 2022

Test ISO strings with extended year -000000 tc39/test262#3470

Merged

ptomato removed the needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 label Apr 9, 2022

IdanHo mentioned this pull request Apr 30, 2022

LibJS: Reject -00000 as extended year in Date parsing SerenityOS/serenity#13853

Merged

rkirsling mentioned this pull request May 10, 2022

Temporal and Date must reject expanded year -000000 WebKit/WebKit#575

Merged

bakkot approved these changes Aug 3, 2022

View reviewed changes

michaelficarra approved these changes Aug 3, 2022

View reviewed changes

bakkot added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Aug 3, 2022

ljharb force-pushed the master branch from aff5c97 to 8edfa9b Compare August 3, 2022 21:49

ljharb merged commit 8edfa9b into tc39:main Aug 3, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: Clarify validity of negative expanded year 0. #2550

Normative: Clarify validity of negative expanded year 0. #2550

EricIO commented Oct 10, 2021

ljharb commented Oct 10, 2021

EricIO commented Oct 10, 2021

ljharb commented Oct 11, 2021

arhadthedev commented Oct 11, 2021

ljharb commented Oct 11, 2021

gibson042 commented Oct 25, 2021

EricIO commented Oct 25, 2021

ljharb commented Oct 25, 2021

EricIO commented Nov 7, 2021

michaelficarra Nov 9, 2021

EricIO Nov 10, 2021

jmdyck Nov 10, 2021

ljharb Nov 10, 2021

ljharb commented Mar 9, 2022

ptomato commented Mar 9, 2022

ljharb commented Mar 9, 2022

ptomato commented Apr 9, 2022

ljharb commented Aug 3, 2022

EricIO commented Aug 4, 2022

Normative: Clarify validity of negative expanded year 0. #2550

Normative: Clarify validity of negative expanded year 0. #2550

Conversation

EricIO commented Oct 10, 2021

ljharb commented Oct 10, 2021

EricIO commented Oct 10, 2021

ljharb commented Oct 11, 2021

arhadthedev commented Oct 11, 2021

ljharb commented Oct 11, 2021

gibson042 commented Oct 25, 2021

EricIO commented Oct 25, 2021

ljharb commented Oct 25, 2021

EricIO commented Nov 7, 2021

michaelficarra Nov 9, 2021

Choose a reason for hiding this comment

EricIO Nov 10, 2021

Choose a reason for hiding this comment

jmdyck Nov 10, 2021

Choose a reason for hiding this comment

ljharb Nov 10, 2021

Choose a reason for hiding this comment

ljharb commented Mar 9, 2022

ptomato commented Mar 9, 2022

ljharb commented Mar 9, 2022

ptomato commented Apr 9, 2022

ljharb commented Aug 3, 2022

EricIO commented Aug 4, 2022