Normative: Use Number arithmetic for constructing dates and times #1564

gibson042 · 2019-05-31T05:11:14Z

Also differentiates the range for time value vs. [[DateValue]], cleans up the text for date and time operations (particularly LocalTZA), and consolidates them where possible.

Can be reviewed commit-by-commit if the merged view is overwhelming.

spectranaut

This is awesome! These changes make the spec way more clear.

spec.html

spectranaut · 2019-08-08T20:34:35Z

spec.html

        <p>where</p>
        <emu-eqn id="eqn-DayWithinYear" aoid="DayWithinYear">DayWithinYear(_t_) = Day(_t_) - DayFromYear(YearFromTime(_t_))</emu-eqn>
-        <p>A month value of 0 specifies January; 1 specifies February; 2 specifies March; 3 specifies April; 4 specifies May; 5 specifies June; 6 specifies July; 7 specifies August; 8 specifies September; 9 specifies October; 10 specifies November; and 11 specifies December. Note that <emu-eqn>MonthFromTime(0) = 0</emu-eqn>, corresponding to Thursday, 01 January, 1970.</p>
+        <p>Note that <emu-eqn>MonthFromTime(0) = 0</emu-eqn>, corresponding to Thursday, 01 January, 1970.</p>


Maybe use <emu-note>? If so, then change the "note" in the Week Day definition to the <emu-note> format, too.

I think this renders better as-is, but will change to <emu-note> if there are strong feelings about it.

spec.html

ljharb · 2019-09-04T17:37:06Z

spec.html

+          1. If _wholeYears_ is not finite, return *NaN*.
+          1. Let _monthWithinYear_ be _m_ modulo 12.
+          1. Let _inLeapYear_ be InLeapYear(TimeFromYear(_wholeYears_)).
+          1. Let _day_ be DayFromYear(_wholeYears_) `+` DaysWithinYearBeforeMonth(_monthWithinYear_, _inLeapYear_) `+` _d_ `-` 1, performing the arithmetic according to IEEE 754-2008 rules (that is, as if using the ECMAScript operators `+` and `-`).


if you use the subscript 𝔽, i don't think you need the "performing …" prose, since that makes them Numbers?

You don't even need the subscript, since it's optional when the operands are Number values, which they presumably are, according to 5.2.5. And the operators don't need backticks either.

even better

Cool; I'll update that. Should multiplication of Number values use * or ×?

Differentiate time values representing instants in (absolute) time from those representing (civil) date and time of day.

Fixes tc39#1087

…in [[DateValue]] UTC/local time calculations near the [[DateValue]] limits can yield integers that exceed them.

…uplicating its logic

…lip immediately after it

bakkot · 2020-05-10T05:35:42Z

@gibson042 Since there's a normative component to this change it needs consensus from the committee. I don't believe it's been discussed yet. Are you interested in presenting the normative component? I can try to do so it if not, though I'm not confident I can give a full and correct accounting of the change.

vmukhachev · 2020-09-30T16:21:54Z

spec.html

-          <p>Local time zone offset values may be positive <i>or</i> negative.</p>
+        </emu-note>
+        <p>When _isUTC_ is *true*, <dfn>LocalTZA( _t_, *true* )</dfn> interprets _t_ as a time value representing an instant in time. It returns the offset of the local time zone from UTC in milliseconds at that instant. When the result is added to _t_, it should yield the time value for which UTC date and time of day are equal to the local date and time of day at time value _t_.</p>
+        <p>When _isUTC_ is *false*, <dfn>LocalTZA( _t_, *false* )</dfn> interprets _t_ as a time value representing a date and time of day. It returns the offset of the local time zone from UTC in milliseconds at the smallest (closest to negative infinity) time value _earliestMatch_ for which either the local date and time of day at _earliestMatch_ is equal to the UTC date and time of day at _t_ or the local date and time of day at _earliestMatch_ + 1 is greater than the UTC date and time of day at _t_. When the result is subtracted from _t_, it should yield the smallest time value for which the local date and time of day are equal to the UTC date and time of day at _t_. If no such time value exists because of local times skipped by positive time zone transitions (e.g. when the daylight saving time starts or the time zone adjustment is increased due to a time zone rule change), then subtracting the result from _t_ should instead yield the time value for which local date and time of day in the UTC offset applicable before the transition are equal to the UTC date and time of day at _t_.</p>


Can this be given in pseudo code?
~~Let localtime be _t_.~~
~~Find smallest integer t for which localtime < t + max(LocalTZA(t - 1, true), LocalTZA(t, true))~~
~~Return localtime - LocalTZA(t - 1, true).~~

I'm not sure at a glance if that expression is correct, and even if it is, the lack of an explanation makes it even harder to follow in my opinion.

@gibson042
It is the same expression as you are using:

Let _earliestMatch_ be the smallest integer for which LocalTime(_earliestMatch_) === _t_ || LocalTime(_earliestMatch_ + 1) > _t_ .
Return _t_ - (LocalTime(_earliestMatch_) - _earliestMatch_) .

where LocalTime is the abstract operation mentioned in the spec.
I think, it can be used together with your explanation, what do you think?

Hmm, I'd rather not introduce cyclic references between the text of isUTC and LocalTime.

@gibson042 , LocalTime calls LocalTZA(t, true), it would be even better to move what LocalTZA(t, false) does into the "UTC".

gibson042

#2120 actually replaces part of this PR, but I think there are still normative changes in MakeDay and MakeDate that will be observable via e.g. Date.UTC( 1970, 0, 1 - 1e8, -BIG, BIG * 60 + 1, 1e8 * 86400 * 2 - 61, 61000 ) (where BIG is at or near Number.MAX_SAFE_INTEGER).

gibson042 · 2020-09-30T21:03:17Z

spec.html

-          <p>Local time zone offset values may be positive <i>or</i> negative.</p>
+        </emu-note>
+        <p>When _isUTC_ is *true*, <dfn>LocalTZA( _t_, *true* )</dfn> interprets _t_ as a time value representing an instant in time. It returns the offset of the local time zone from UTC in milliseconds at that instant. When the result is added to _t_, it should yield the time value for which UTC date and time of day are equal to the local date and time of day at time value _t_.</p>
+        <p>When _isUTC_ is *false*, <dfn>LocalTZA( _t_, *false* )</dfn> interprets _t_ as a time value representing a date and time of day. It returns the offset of the local time zone from UTC in milliseconds at the smallest (closest to negative infinity) time value _earliestMatch_ for which either the local date and time of day at _earliestMatch_ is equal to the UTC date and time of day at _t_ or the local date and time of day at _earliestMatch_ + 1 is greater than the UTC date and time of day at _t_. When the result is subtracted from _t_, it should yield the smallest time value for which the local date and time of day are equal to the UTC date and time of day at _t_. If no such time value exists because of local times skipped by positive time zone transitions (e.g. when the daylight saving time starts or the time zone adjustment is increased due to a time zone rule change), then subtracting the result from _t_ should instead yield the time value for which local date and time of day in the UTC offset applicable before the transition are equal to the UTC date and time of day at _t_.</p>


I'm not sure at a glance if that expression is correct, and even if it is, the lack of an explanation makes it even harder to follow in my opinion.

bakkot · 2020-09-30T23:55:00Z

At the last meeting I asked for (and achieved) consensus that all arithmetic on Date objects was to be done with Number semantics, particularly calling out the large number cases, so I think the normative parts are good to go unless they entail changes beyond that.

I was planning to make that particular change as a part of #2007 (which makes it unambiguous when arithmetic is being done as if on reals vs as if on Numbers). Unfortunately that PR is going to have a bunch of conflicts with this one; when we were working on it I'd forgotten you already made this PR. I'll need to rebase one of them.

gibson042 · 2020-10-01T03:38:31Z

@bakkot Please continue to disregard this PR when addressing arithmetic, it's really more about clarifying Date semantics than about any particular types or order of operations. I'll be happy to rebase it (but please do keep #1087 in mind with your changes).

michaelficarra · 2023-05-01T19:44:37Z

@gibson042 Is this PR still applicable after #2007?

gibson042 · 2023-05-01T20:48:47Z

No, I don't think so. Simplify MonthFromTime and Dedicate a subsection to time value range and Refactor InLeapYear(t) as LeapDaysInYear(y) are editorial changes that could be added independently if deemed desirable, and everything else has already been superseded.

gibson042 added normative change Affects behavior required to correctly evaluate some ECMAScript source text needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 labels May 31, 2019

spectranaut reviewed Aug 8, 2019

View reviewed changes

gibson042 force-pushed the gh-1087-time-arithmetic-precision branch from e5c9eb0 to d6b339c Compare September 4, 2019 16:52

ljharb reviewed Sep 4, 2019

View reviewed changes

ljharb force-pushed the gh-1087-time-arithmetic-precision branch from a754929 to c5b118b Compare September 5, 2019 05:12

gibson042 added 12 commits October 3, 2019 18:25

Editorial: Clarify time value comparison and conversion

e57ab2f

Differentiate time values representing instants in (absolute) time from those representing (civil) date and time of day.

Normative: Use Number arithmetic for constructing dates and times

a43674c

Fixes tc39#1087

Editorial: Only restrict time values more tightly than safe integers …

0a64fb4

…in [[DateValue]] UTC/local time calculations near the [[DateValue]] limits can yield integers that exceed them.

Editorial: Clean up time value operation text

010b362

Editorial: Consolidate time value operations

ee9f593

Editorial: Refactor InLeapYear to rely upon DayFromYear rather than d…

ad9cfff

…uplicating its logic

Editorial: Simplify MonthFromTime

1dde075

Editorial: Dedicate a subsection to time value range and define TimeC…

7f6553f

…lip immediately after it

Editorial: Refactor InLeapYear(_t_) as LeapDaysInYear(_y_)

e4b9b2d

Editorial: Improve the explanation of LocalTZA

0b55c59

Fix a LocalTZA( _t_, false ) edge case

4facda5

Editorial: Improve the note for LocalTime

88c606e

gibson042 force-pushed the gh-1087-time-arithmetic-precision branch from c5b118b to 88c606e Compare October 6, 2019 16:49

gibson042 mentioned this pull request Oct 9, 2019

Editorial: Better relate ECMAScript time values to POSIX and UTC #1325

Merged

vmukhachev reviewed Sep 30, 2020

View reviewed changes

ljharb added the needs consensus This needs committee consensus before it can be eligible to be merged. label Sep 30, 2020

gibson042 commented Sep 30, 2020

View reviewed changes

ljharb force-pushed the master branch 3 times, most recently from 3d0c24c to 7a79833 Compare June 29, 2021 02:21

ptomato mentioned this pull request May 7, 2022

MakeDay should be more explicit how unreasonably large numbers are handled #1087

Open

anba mentioned this pull request Jun 17, 2022

Review MakeDay/MakeDate/TimeFromYear callers for possibly out-of-range values tc39/proposal-temporal#2315

Closed

gibson042 closed this May 1, 2023

ptomato mentioned this pull request Oct 2, 2023

Editorial: Convert Date-related equations into proper AOs #3092

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: Use Number arithmetic for constructing dates and times #1564

Normative: Use Number arithmetic for constructing dates and times #1564

gibson042 commented May 31, 2019

spectranaut left a comment

spectranaut Aug 8, 2019

gibson042 Aug 15, 2019

ljharb Sep 4, 2019

jmdyck Sep 4, 2019

ljharb Sep 4, 2019

gibson042 Sep 4, 2019

bakkot commented May 10, 2020

vmukhachev Sep 30, 2020 •

edited

Loading

gibson042 Sep 30, 2020

Yaffle Oct 1, 2020 •

edited

Loading

gibson042 Oct 1, 2020

Yaffle Oct 1, 2020 •

edited

Loading

gibson042 left a comment

gibson042 Sep 30, 2020

bakkot commented Sep 30, 2020

gibson042 commented Oct 1, 2020

michaelficarra commented May 1, 2023

gibson042 commented May 1, 2023

Normative: Use Number arithmetic for constructing dates and times #1564

Normative: Use Number arithmetic for constructing dates and times #1564

Conversation

gibson042 commented May 31, 2019

spectranaut left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bakkot commented May 10, 2020

vmukhachev Sep 30, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yaffle Oct 1, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yaffle Oct 1, 2020 • edited Loading

Choose a reason for hiding this comment

gibson042 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bakkot commented Sep 30, 2020

gibson042 commented Oct 1, 2020

michaelficarra commented May 1, 2023

gibson042 commented May 1, 2023

vmukhachev Sep 30, 2020 •

edited

Loading

Yaffle Oct 1, 2020 •

edited

Loading

Yaffle Oct 1, 2020 •

edited

Loading