Normative: Fix out-of-range NaNs in date set methods

[devsnek]

Marked as editoral due to current text being nonsensical and new text matching implementations.

[bakkot]

Looks good. Couple of consistency things:

• setFullYear, setUTCFullYear, and setYear already have guards on NaN. In those cases the guard isn't side-effecting, and hence can come either before or after the observable ToNumber coercions. Those existing ones are written before the coercion, whereas the new ones are after. It'd be good to move the existing ones to after as well, so they match.
• I think we should also avoid passing NaN to LocalTime. In other places that's explicitly prevented. So it would be good to move the call to LocalTime after the NaN check, as in

1. Let _t_ be ? thisTimeValue(*this* value).
1. Let _dt_ be ? ToNumber(_date_).
1. If _t_ is *NaN*, return *NaN*
1. Set _t_ to LocalTime(_t_).

[michaelficarra]

Is this editorial?

[bakkot]

Is this editorial?

I think so: the current state is nonsensical by a strict reading and the only plausible interpretation by a loose reading (that floor(NaN), etc, return NaN) matches the semantics in this PR.

[ljharb]

hmm - DateFromTime takes a time value which is allowed to be NaN, for example - so i think that the fix isn't "don't call DateFromTime with NaN", it's maybe "add an explicit step inside each of these operations that returns NaN if NaN is provided"?

(similarly for the other examples in this PR)

[bakkot]

I would strongly prefer to filter out NaN as early and explicitly as possible, rather than adding a special case for it in each intermediate operation.

[ljharb]

These operations already are defined to accept a time value, which allows NaN - so if we want to make that change, we also have to redefine all of them to only accept integers.

[bakkot]

I am happy to additionally add the word "finite" before the words "time value" in the headers of the various intermediate operations, sure.

[bakkot]

I've updated this to be more thorough. Unfortunately, in some of these cases there were multiple plausible interpretations and engines do not agree, so I've marked this as normative.

Specifically, when invoking the set methods which have optional higher-precision arguments (like setHour) on an invalid Date object, there is not agreement on which arguments should be coerced before returning. For example,

(new Date(NaN)).setHours(
  { valueOf(){ print('coerced hour'); } },
  { valueOf(){ print('coerced min'); } },
  { valueOf(){ print('coerced sec'); } },
  { valueOf(){ print('coerced ms'); } },
);

produces

┌─────┬──────────────┐
│ ch  │ coerced hour │
│ v8  │              │
├─────┼──────────────┤
│ jsc │              │
├─────┼──────────────┤
│ sm  │ coerced hour │
│ xs  │ coerced min  │
│     │ coerced sec  │
│     │ coerced ms   │
└─────┴──────────────┘

The semantics I've specified in this PR match Spidermonkey's behavior, since it seemed the most natural to me and because I believe it matches the intent of the the spec as written.

[michaelficarra]

I'd prefer if we consistently named these newDate.

[bakkot]

Rebased. I've also opened a PR with tests: tc39/test262#3362. Once those land, so can this.

Edit: landed.

[syg]

lgtm