Change Date.parse to round milliseconds down

[gibson042]

Describe
XS appears to be the only ECMAScript implementation with round-to-nearest millisecond Date.parse (and by extension, new Date(value)) behavior:

$ eshost -se '
  [
    "1970-01-01T00:00:00.000500001Z",
    "1969-12-31T23:59:59.999515625Z",
    "1969-12-31T23:59:59.999015625Z",
  ]
  .map(str => {
    const tv = Date.parse(str);
    return `${str} => ${(new Date(str)).toISOString()} (${Object.is(tv, -0) ? "-0" : tv} ms from epoch)`;
  })
  .join("\n")
'
#### ChakraCore, engine262, GraalJS, Hermes, SpiderMonkey, V8
1970-01-01T00:00:00.000500001Z => 1970-01-01T00:00:00.000Z (0 ms from epoch)
1969-12-31T23:59:59.999515625Z => 1969-12-31T23:59:59.999Z (-1 ms from epoch)
1969-12-31T23:59:59.999015625Z => 1969-12-31T23:59:59.999Z (-1 ms from epoch)

#### JavaScriptCore
1970-01-01T00:00:00.000500001Z => 1970-01-01T00:00:00.000Z (0.500001 ms from epoch)
1969-12-31T23:59:59.999515625Z => 1970-01-01T00:00:00.000Z (-0.484375 ms from epoch)
1969-12-31T23:59:59.999015625Z => 1970-01-01T00:00:00.000Z (-0.984375 ms from epoch)

#### Moddable XS
1970-01-01T00:00:00.000500001Z => 1970-01-01T00:00:00.001Z (1 ms from epoch)
1969-12-31T23:59:59.999515625Z => 1970-01-01T00:00:00.000Z (0 ms from epoch)
1969-12-31T23:59:59.999015625Z => 1969-12-31T23:59:59.999Z (-1 ms from epoch)

I think it would be better to round down (i.e., towards negative infinity), yielding results equivalent to ignoring all digits beyond millisecond precision.

Why do you think this feature would be useful?
It would align with the majority of other implementations, and completely eliminate a unique behavior from the landscape (note that the JSC behavior isn't even spec-compliant, and has been reported). And because rounding up date-time values is relatively uncommon, it would likely also reduce developer surprise (especially when rounding crossing coarse boundaries, such as the above example where parsing a "1969-…Z" string returns a time value in 1970).

Describe alternatives you've considered
The current behavior is technically compliant with the underspecified https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date.parse , and there is no requirement to change it. I just think that doing so would be useful.

[phoddie]

Thanks for the report. No question that it is desirable to have a consistent behavior across engines here. We'll have to take a look to see what's involved.

[phoddie]

Maybe we just need to change from c_round to c_trunc here. At least that gives the expected result.

[gibson042]

Yes, that looks right to me. Or alternatively, increasing aResult only while fraction >= 1 (provided theCharacter and theString still advance past all the digits).