Normative: Cleanup Time Values and Time Range #1144

apaprocki · 2018-03-21T10:48:21Z

Implementations are not currently consistently limiting time values to the spec defined ranges of both time value and extended years.

This change is editorial cleanup that more clearly states the allowed time value range and the supported range of extended years that fit within the allowed time value range.

Implementations will need to be updated to conform with the spec (SM currently adheres) and pass the accompanying test in tc39/test262#1501.

Concrete examples of what will be fixed are detailed in #1145.

Time Values and Time Range:

Language about Number range in hundreds-of-thousands of years plus/minus UTC epoch is not immediately relevant; move it to an emu-note
New emu-note text fixes inconsistency in spec where this section was not properly accounting for leap years when computing the approximate number of years in the maximum range but 20.3.1.15.1 extended years was stating it correctly
Add emu-xref for Number integer range
Add comment referring to POSIX day for the source of 86,400 seconds
Simplify remaining spec in section into clear, consistent language

Extended Years:

Add dfn to extended years so it is linked from format section
Add emu-xref for time value range
Explicitly state extended years relation to time value range
Explicitly state ISO 8601 strings outside time value range are not accepted
Modify extended years example table to reflect the proper minimum/maximum values allowed by the time value range

maggiepint · 2018-03-21T21:42:29Z

spec.html

-        <p>The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly -100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC.</p>
-        <p>The exact moment of midnight at the beginning of 01 January, 1970 UTC is represented by the value *+0*.</p>
+        <p>A Date object contains a Number representing an instant in time with millisecond precision. Such a Number is called a <dfn>time value</dfn>. A time value may also be *NaN*, indicating that the Date object does not represent a specific instant in time.</p>
+        <p>Time is measured in ECMAScript as milliseconds since midnight at the beginning of 01 January, 1970 UTC. Time in ECMAScript does not observe leap seconds; they are ignored. Time calculations assume a day contains exactly <emu-eqn>60 &times; 60 &times; 24 &times; 1000 = 86,400,000</emu-eqn> milliseconds.</p>


If we are going this deep, do we want to discuss why we don't support leap seconds? I feel like that gets asked a lot, and of course it goes back to the fact that we're fundamentally using Unix time which doesn't support them here.

Small nit - I believe we should say time calculations assume a UTC day contains exactly...

I believe we should say time calculations assume a UTC day contains exactly...

(I.e., inserting "UTC".) I think we should go in the opposite direction, removing most mentions of UTC, for the very reason that ES doesn't support leap seconds.

@maggiepint I can ask around tomorrow, but there might be some reason why Unix / POSIX can't be referenced specifically in the spec (neither are currently).

@jmdyck I'd tend to agree re: leaving UTC out when referring to the length of a day. One of the most common references for people (Wikipedia) clearly states a UTC day sometimes contains an extra second, so it would be like the spec saying "A UTC day is not a UTC day".

As for removing most mentions of UTC, the spec currently has 69 lines that mention UTC at least once. Even if removal is technically sound, careful wording would have to replace it and it's a larger proposal that would have to be discussed separately.

As for removing most mentions of UTC, [...] it's a larger proposal that would have to be discussed separately.

Agreed.

I suppose UTC isn't right.

What I'm going for is not local, because of course the spec does support
local time which, due to DST or zone splitting, has days not of that length.

I asked @bterlson and he didn't see an issue with mentioning the alignment with the POSIX specification of a day, so see my last push for proposed wording.

@jmdyck When looking back over the POSIX spec, it appears they did exactly as you are suggesting and changed all references from "seconds since 00:00:00 UTC (Coordinated
Universal Time), January 1 1970" to "seconds since the Epoch". I'd be ok with attempting to tackle that as a subsequent PR. I'm guessing that might need to be brought up to the committee because it would likely involve defining the ES Epoch explicitly as 1970-01-01T00:00:00 TAI and adding similar implementation-defined language that POSIX resorted to:

The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.

How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

littledan

Seems like a generally nice editorial change, add a little more background.

littledan · 2018-04-04T07:42:36Z

spec.html

+                  <tr>
+                    <td>+275760-09-13T00:00:00Z</td>
+                    <td>275760 A.D.</td>
+                  </tr>


What is the purpose of the addition of these extended years? It doesn't look like they are boundary cases, due to the more extremely values preceding and following them.

Oh I see, these are what you are separately proposing to be the new extreme permitted values, right?

apaprocki · 2018-04-04T12:18:23Z

@littledan I added further text clarifying Extended Years as noted and I removed the min/max safe integers from the example table since they lie outside the time value range and could be confusing. This should also take care of #1145 and allow you to approve tc39/test262#1501?

littledan

Given that the interpretation of the previous text has been debated, and this patch is intended to nail down one possibly, I think we should consider this a normative change and get the appropriate input on it before landing. The first thing would be to mark it Normative: rather than Editorial:

apaprocki · 2018-04-05T14:46:58Z

@littledan I reformatted this as a single normative commit. I'll add the PR onto the agenda for May.

littledan · 2018-04-05T16:36:58Z

For good measure, let's see if we can get in touch with implementers ahead of time to see how they would feel about making this change in their JS engines:

cc @hashseed @jungshik @bterlson @kmiller68

littledan · 2018-04-19T18:29:53Z

spec.html

@@ -27723,15 +27728,15 @@ <h1>Date Time String Format</h1>
        <!-- es6num="20.3.1.16.1" -->
        <emu-clause id="sec-extended-years">
          <h1>Extended Years</h1>
-          <p>ECMAScript requires the ability to specify 6 digit years (extended years); approximately 285,426 years, either forward or backward, from 01 January, 1970 UTC. To represent years before 0 or after 9999, ISO 8601 permits the expansion of the year representation, but only by prior agreement between the sender and the receiver. In the simplified ECMAScript format such an expanded year representation shall have 2 extra year digits and is always prefixed with a + or - sign. The year 0 is considered positive and hence prefixed with a + sign.</p>
+          <p>ECMAScript requires the ability to specify 6 digit years, or <dfn>extended years</dfn>, to render the full range of a time value; -100,000,000 days to 100,000,000 days, or approximately -273,790 to 273,790 years, relative to midnight at the beginning of 01 January, 1970 UTC (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>). To represent years before 0 or after 9999, ISO 8601 permits the expansion of the year representation, but only by prior agreement between the sender and the receiver. In the simplified ECMAScript format such an expanded year representation shall have 2 extra year digits and is always prefixed with a + or - sign. The year 0 is considered positive and hence prefixed with a + sign. ISO 8601 formatted strings with extended years representing points in time outside the range of a time value are not accepted.</p>


I'm not sure if "ISO 8601 formatted strings with extended years representing points in time outside the range of a time value are not accepted." makes it clear that these date/time strings will result in an Invalid Date rather than being allowed to fall back to the implementation-specific parser. I think it'd be best if this behavior were explicitly described in Date.parse. (Apologies for not mentioning this the first time around.)

The new text

ISO 8601 formatted strings with extended years representing points in time outside the range of a time value are represented as the Number NaN when parsed by Date.parse() and do not fall back to implementation-specific behavior or heuristics.

Looks great to me. Thanks for the clarification.

msaboff · 2018-05-22T14:51:28Z

JSC Bug filed https://bugs.webkit.org/show_bug.cgi?id=185868 - "Date.parse() doesn't properly handle input outside of ES Spec limits"

mathiasbynens · 2018-05-22T14:54:31Z

V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=7781

apaprocki · 2018-05-23T01:58:45Z

@littledan I believe I addressed your last concern by explicitly stating

are represented as the Number NaN when parsed by Date.parse() and do not fall back to implementation-specific behavior or heuristics.

instead of

are not accepted.

This area of Date.parse could be cleaned up later under work you were suggesting, but this should be very clear in the meantime.

apaprocki · 2018-06-05T08:07:43Z

@ljharb can this be merged now? @rwaldron already merged the related test262

apaprocki · 2018-06-05T10:39:14Z

@littledan it seems like somehow this lost your review, could you re-ack?

apaprocki · 2018-07-07T15:02:30Z

@ljharb @bterlson can this be merged now? It’s been lingering, thanks

ljharb · 2018-07-07T16:25:31Z

Now that ES2018 is finalized, we'll look at this in our next editor's meeting.

Implementations are not currently consistently limiting *time values* to the spec defined ranges of both *time value* and *extended years*. This change is editorial cleanup that more clearly states the allowed *time value* range and the supported range of *extended years* that fit within the allowed *time value* range. Implementations will need to be updated to conform with the spec (SM currently adheres) and pass the accompanying test in tc39/test262#1501. Time Values and Time Range: - Language about `Number` range in hundreds-of-thousands of years plus/minus UTC epoch is not immediately relevant; move it to an `emu-note` - New `emu-note` text fixes inconsistency in spec where this section was not properly accounting for leap years when computing the approximate number of years in the maximum range but 20.3.1.15.1 *extended years* was stating it correctly - Add `emu-xref` for Number integer range - Add comment referring to POSIX day for the source of 86,400 seconds - Simplify remaining spec in section into clear, consistent language Extended Years: - Add `dfn` to *extended years* so it is linked from format section - Add `emu-xref` for *time value* range - Explicitly state *extended years* relation to *time value* range - Explicitly state ISO 8601 strings outside *time value* range are not accepted - Modify *extended years* example table to reflect the proper minimum/maximum values allowed by the *time value* range - More forceful Extended Years text: explicitly state *NaN* is returned instead of "are not accepted."

ljharb added the editorial change label Mar 21, 2018

ljharb requested review from bterlson, bmeck and maggiepint March 21, 2018 10:50

maggiepint reviewed Mar 21, 2018

View reviewed changes

littledan approved these changes Apr 4, 2018

View reviewed changes

littledan approved these changes Apr 5, 2018

View reviewed changes

littledan suggested changes Apr 5, 2018

View reviewed changes

rwaldron mentioned this pull request Apr 5, 2018

Date.parse breathing test, time value maximum range test tc39/test262#1501

Merged

ljharb added normative change Affects behavior required to correctly evaluate some ECMAScript source text needs consensus This needs committee consensus before it can be eligible to be merged. and removed editorial change labels Apr 5, 2018

apaprocki force-pushed the time-value-range-editorial branch from 0470265 to 6f52edf Compare April 5, 2018 14:46

apaprocki changed the title ~~Editorial: Cleanup Time Values and Time Range~~ Normative: Cleanup Time Values and Time Range Apr 5, 2018

anba mentioned this pull request Apr 18, 2018

Inconsistencies and errors in the time range supported by Date #1176

Open

littledan reviewed Apr 19, 2018

View reviewed changes

michaelficarra mentioned this pull request Apr 28, 2018

sorting proposal-based agenda items primarily by current stage tc39/agendas#360

Closed

rwaldron added has consensus This has committee consensus. and removed needs consensus This needs committee consensus before it can be eligible to be merged. labels May 22, 2018

ljharb added the has test262 tests label Jun 5, 2018

ljharb approved these changes Jun 5, 2018

View reviewed changes

ljharb assigned bterlson Jun 5, 2018

littledan approved these changes Jun 8, 2018

View reviewed changes

bmeck approved these changes Jul 18, 2018

View reviewed changes

bterlson approved these changes Aug 1, 2018

View reviewed changes

ljharb assigned ljharb and unassigned bterlson Aug 1, 2018

bterlson approved these changes Aug 1, 2018

View reviewed changes

ljharb force-pushed the time-value-range-editorial branch from 6f6d19b to 2e2a3d4 Compare August 1, 2018 19:34

ljharb merged commit 2e2a3d4 into tc39:master Aug 1, 2018

This was referenced Aug 1, 2018

20.3.3.2 Date.parse does not explicitly state out-of-range time values return NaN #1145

Closed

Editorial: Update date-time format language #1252

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: Cleanup Time Values and Time Range #1144

Normative: Cleanup Time Values and Time Range #1144

apaprocki commented Mar 21, 2018 •

edited

Loading

maggiepint Mar 21, 2018

jmdyck Mar 21, 2018

apaprocki Mar 22, 2018

jmdyck Mar 22, 2018

maggiepint Mar 22, 2018

apaprocki Mar 23, 2018

littledan left a comment

littledan Apr 4, 2018

littledan Apr 4, 2018

apaprocki commented Apr 4, 2018

littledan left a comment •

edited

Loading

apaprocki commented Apr 5, 2018

littledan commented Apr 5, 2018

littledan Apr 19, 2018

littledan May 25, 2018

msaboff commented May 22, 2018

mathiasbynens commented May 22, 2018

apaprocki commented May 23, 2018

apaprocki commented Jun 5, 2018

apaprocki commented Jun 5, 2018

apaprocki commented Jul 7, 2018

ljharb commented Jul 7, 2018

Normative: Cleanup Time Values and Time Range #1144

Normative: Cleanup Time Values and Time Range #1144

Conversation

apaprocki commented Mar 21, 2018 • 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

Choose a reason for hiding this comment

littledan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apaprocki commented Apr 4, 2018

littledan left a comment • edited Loading

Choose a reason for hiding this comment

apaprocki commented Apr 5, 2018

littledan commented Apr 5, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msaboff commented May 22, 2018

mathiasbynens commented May 22, 2018

apaprocki commented May 23, 2018

apaprocki commented Jun 5, 2018

apaprocki commented Jun 5, 2018

apaprocki commented Jul 7, 2018

ljharb commented Jul 7, 2018

apaprocki commented Mar 21, 2018 •

edited

Loading

littledan left a comment •

edited

Loading