Editorial: More tweaks to low-level Date AOs #3193

jmdyck · 2023-10-12T01:47:04Z

This is a follow-up to PR #3092.

The first two commits:

inline DaysInYear into InLeapYear, and
rename msFromTime as MillisecFromTime

as suggested at the bottom of this comment.

The remaining commits try to shift things in this area from integral Numbers to mathematical integers, as suggested by michaelficarra and syg.

Note that this doesn't have much effect on the space in which arithmetic is done. Mostly it just avoids unnecessary conversions between the two. Roughly, the idea is to delay 𝔽 calls as much as reasonable.

(I've submitted this part as one commit per AO, in case that helps with review, but I expect I'll squash them down to one commit for merging.)

Effects on downstream specs:
None for WebIDL and HTML.

In Ecma 402, Table 8 uses WeekDay() and the various FooFromTime() AOs to set the fields of the record returned by ToLocalTime(). Since this PR changes the return value of these AOs from an integral Number to a mathematical integer, we might expect that 402 would need to change. However, the uses of ToLocalTime (in FormatDateTimePattern and PartitionDateTimeRangePattern) actually seem happier with mathematical values than Numbers in these fields.

As for the Temporal proposal, I'll let others decide whether this PR makes things better or worse for it.

anba · 2023-10-12T05:28:20Z

In Ecma 402, Table 8 uses WeekDay() and the various FooFromTime() AOs to set the fields of the record returned by ToLocalTime(). Since this PR changes the return value of these AOs from an integral Number to a mathematical integer,
we might expect that 402 would need to change. However, the uses of ToLocalTime (in FormatDateTimePattern and PartitionDateTimeRangePattern)
actually seem happier with mathematical values than Numbers in these fields.

I can confirm this. tc39/ecma402#822 will change ECMA-402 to convert the current 𝔽 outputs to ℝ. This won't be necessary anymore when ECMA-262 already returns ℝ values.

jmdyck · 2024-01-25T02:01:29Z

(force-pushed to resolve a merge conflict)

spec.html

michaelficarra · 2024-02-15T22:46:09Z

There's a call to MakeDay in a note in the UTC AO that passes mathematical values. If you rebase, you should get a version of ecmarkup that would catch this.

That said, a lot of calls to MakeTime/MakeDay/MakeDate convert mathematical values to Numbers before getting converted right back. What would it look like to make them take/produce maths values instead?

michaelficarra

LGTM otherwise, but we should explore changing the types of MakeTime/MakeDay/MakeDate before landing (or as a follow-up).

syg · 2024-02-21T22:52:46Z

spec.html

        </h1>
        <dl class="header">
          <dt>description</dt>
-          <dd>It returns a Number identifying the month in which _t_ falls. A month value of *+0*<sub>𝔽</sub> specifies January; *1*<sub>𝔽</sub> specifies February; *2*<sub>𝔽</sub> specifies March; *3*<sub>𝔽</sub> specifies April; *4*<sub>𝔽</sub> specifies May; *5*<sub>𝔽</sub> specifies June; *6*<sub>𝔽</sub> specifies July; *7*<sub>𝔽</sub> specifies August; *8*<sub>𝔽</sub> specifies September; *9*<sub>𝔽</sub> specifies October; *10*<sub>𝔽</sub> specifies November; and *11*<sub>𝔽</sub> specifies December. Note that <emu-eqn>MonthFromTime(*+0*<sub>𝔽</sub>) = *+0*<sub>𝔽</sub></emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>
+          <dd>It returns a Number identifying the month in which _t_ falls. 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*<sub>𝔽</sub>) = 0</emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>


Suggested change

<dd>It returns a Number identifying the month in which _t_ falls. 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, 1 January 1970.</dd>

<dd>It returns an integer identifying the month in which _t_ falls. 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, 1 January 1970.</dd>

syg · 2024-02-21T22:53:20Z

spec.html

        </h1>
        <dl class="header">
          <dt>description</dt>
-          <dd>It returns a Number identifying the day of the week in which _t_ falls. A weekday value of *+0*<sub>𝔽</sub> specifies Sunday; *1*<sub>𝔽</sub> specifies Monday; *2*<sub>𝔽</sub> specifies Tuesday; *3*<sub>𝔽</sub> specifies Wednesday; *4*<sub>𝔽</sub> specifies Thursday; *5*<sub>𝔽</sub> specifies Friday; and *6*<sub>𝔽</sub> specifies Saturday. Note that <emu-eqn>WeekDay(*+0*<sub>𝔽</sub>) = *4*<sub>𝔽</sub></emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>
+          <dd>It returns a Number identifying the day of the week in which _t_ falls. A weekday value of 0 specifies Sunday; 1 specifies Monday; 2 specifies Tuesday; 3 specifies Wednesday; 4 specifies Thursday; 5 specifies Friday; and 6 specifies Saturday. Note that <emu-eqn>WeekDay(*+0*<sub>𝔽</sub>) = 4</emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>


Suggested change

<dd>It returns a Number identifying the day of the week in which _t_ falls. A weekday value of 0 specifies Sunday; 1 specifies Monday; 2 specifies Tuesday; 3 specifies Wednesday; 4 specifies Thursday; 5 specifies Friday; and 6 specifies Saturday. Note that <emu-eqn>WeekDay(*+0*𝔽) = 4</emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>

<dd>It returns an integer identifying the day of the week in which _t_ falls. A weekday value of 0 specifies Sunday; 1 specifies Monday; 2 specifies Tuesday; 3 specifies Wednesday; 4 specifies Thursday; 5 specifies Friday; and 6 specifies Saturday. Note that <emu-eqn>WeekDay(*+0*𝔽) = 4</emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>

bakkot · 2024-02-21T23:00:08Z

This will need to be paired with an update to the Temporal spec, which @michaelficarra has volunteered to do.

jmdyck · 2024-02-27T01:46:27Z

There's a call to MakeDay in a note in the UTC AO that passes mathematical values.

Yup. Since it's a Note, I thought it could be looser. But I can insert subscripts if you like.

If you rebase, you should get a version of ecmarkup that would catch this.

I pushed up a rebase, but all checks passed.

That said, a lot of calls to MakeTime/MakeDay/MakeDate convert mathematical values to Numbers before getting converted right back. What would it look like to make them take/produce maths values instead?

If every argument in every call to MakeTime & MakeDay were F(_m_) where _m_ was some finite and not-too-big mathematical value, then yes we could do some simplification and end up directly passing _m_. But that's not case: in almost every call, some args are arbitrary Number values, which have to be caught by the 'not finite' test in step 1 of MakeTime and MakeDay. You could hoist that test out to the call-sites, but I don't think that would be an improvement.

Moreover, MakeDay has two other steps that can return *NaN*: what should it do there if it can only produce math values?

... to follow that convention that an AO name starts with a capital letter.

…e.toUTCString (some internals only) Generally, this just delays invocations of overstruck-F. In some cases, this causes some comparisons (but not arithmetic) to shift from Number to mathematical.

jmdyck · 2024-07-11T17:16:07Z

(force-pushed to resolve merge conflicts)

jmdyck added the editorial change label Oct 12, 2023

jmdyck force-pushed the Date_math branch from 39672b0 to c4eaa9a Compare January 25, 2024 02:01

michaelficarra reviewed Feb 15, 2024

View reviewed changes

spec.html Outdated Show resolved Hide resolved

michaelficarra approved these changes Feb 15, 2024

View reviewed changes

syg reviewed Feb 21, 2024

View reviewed changes

jmdyck force-pushed the Date_math branch from c4eaa9a to 642d237 Compare February 26, 2024 21:10

jmdyck added 19 commits July 11, 2024 09:01

Editorial: Inline DaysInYear into InLeapYear

22119f4

Editorial: Rename msFromTime as MillisecFromTime

8fc556c

... to follow that convention that an AO name starts with a capital letter.

to math: msPerFoo constants

c8ba24a

to math: Day (return value)

a057a15

to math: TimeWithinDay (return value)

bb1a1ce

to math: DayFromYear (parameter + return value)

6374d53

to math: TimeFromYear (parameter)

98b079a

to math: YearFromTime (return value)

daf7061

to math: DayWithinYear (return value)

ebcecf7

to math: InLeapYear (return value)

4f6c274

to math: MonthFromTime (return value + internal aliases)

bcf70ac

to math: DateFromTime (return value + internal aliases)

f244ea8

to math: WeekDay (return value)

8bd779a

to math: HourFromTime (return value)

062572d

to math: MinFromTime (return value)

6a438de

to math: SecFromTime (return value)

07987df

to math: MillisecFromTime (return value)

0de9f1a

to math: "Names of days of the week" table

c351bd4

to math: "Names of months of the year" table

36df3cc

jmdyck added 2 commits July 11, 2024 09:01

to math: MakeTime, MakeDay, DateString, TimeZoneString, Date.prototyp…

80fe050

…e.toUTCString (some internals only) Generally, this just delays invocations of overstruck-F. In some cases, this causes some comparisons (but not arithmetic) to shift from Number to mathematical.

fixup: fix description of MonthFromTime and WeekDay

38864d6

jmdyck force-pushed the Date_math branch from 5efbad4 to 38864d6 Compare July 11, 2024 17:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editorial: More tweaks to low-level Date AOs #3193

Editorial: More tweaks to low-level Date AOs #3193

jmdyck commented Oct 12, 2023 •

edited

Loading

anba commented Oct 12, 2023

jmdyck commented Jan 25, 2024

michaelficarra commented Feb 15, 2024 •

edited

Loading

michaelficarra left a comment •

edited

Loading

syg Feb 21, 2024

jmdyck Feb 28, 2024

syg Feb 21, 2024

jmdyck Feb 28, 2024

bakkot commented Feb 21, 2024

jmdyck commented Feb 27, 2024

jmdyck commented Jul 11, 2024

	<dd>It returns a Number identifying the day of the week in which _t_ falls. A weekday value of 0 specifies Sunday; 1 specifies Monday; 2 specifies Tuesday; 3 specifies Wednesday; 4 specifies Thursday; 5 specifies Friday; and 6 specifies Saturday. Note that <emu-eqn>WeekDay(+0<sub>𝔽</sub>) = 4</emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>
	<dd>It returns an integer identifying the day of the week in which _t_ falls. A weekday value of 0 specifies Sunday; 1 specifies Monday; 2 specifies Tuesday; 3 specifies Wednesday; 4 specifies Thursday; 5 specifies Friday; and 6 specifies Saturday. Note that <emu-eqn>WeekDay(+0<sub>𝔽</sub>) = 4</emu-eqn>, corresponding to Thursday, 1 January 1970.</dd>

Editorial: More tweaks to low-level Date AOs #3193

Are you sure you want to change the base?

Editorial: More tweaks to low-level Date AOs #3193

Conversation

jmdyck commented Oct 12, 2023 • edited Loading

anba commented Oct 12, 2023

jmdyck commented Jan 25, 2024

michaelficarra commented Feb 15, 2024 • edited Loading

michaelficarra left a comment • edited Loading

Choose a reason for hiding this comment

syg Feb 21, 2024

Choose a reason for hiding this comment

jmdyck Feb 28, 2024

Choose a reason for hiding this comment

syg Feb 21, 2024

Choose a reason for hiding this comment

jmdyck Feb 28, 2024

Choose a reason for hiding this comment

bakkot commented Feb 21, 2024

jmdyck commented Feb 27, 2024

jmdyck commented Jul 11, 2024

jmdyck commented Oct 12, 2023 •

edited

Loading

michaelficarra commented Feb 15, 2024 •

edited

Loading

michaelficarra left a comment •

edited

Loading