[Webkit-unassigned] [Bug 238050] [JSC] Change Date.parse to stop returning numbers with fractional part

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=238050

--- Comment #1 from Yusuke Suzuki <ysuzuki at apple.com> ---
(In reply to Richard Gibson from comment #0)
> JavaScriptCore `Date.parse` can return non-integer non-NaN numbers, in
> violation of
> https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date.parse
> (which requires the output to be a _time value_—"either a finite **integral
> Number** representing an instant in time to millisecond precision or NaN
> representing no specific instant" [cf.
> https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-time-values-and-
> time-range ]):
> ```sh
> $ 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)

I think this looks very strange: if we perform TimeClip operation (https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-timeclip),
then all results should be 0 ms since TimeClip is effectively trunc operation.

I think the reasonable behavior is +0 for all three inputs.

> 
> #### 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)
> ```
> 
> And worse, this results in bizarre round-towards-epoch behavior in new Date
> construction (as seen above).

I think this is the right behavior. TimeClip is trunc.
Let's see

`new Date(-0.484375).valueOf()` => 0 in all engines.

> 
> Any rounding behavior would correct this bug, but I think it would be best
> to align with the majority of other implementations in specifically rounding
> time values down (i.e., towards negative infinity), yielding results
> equivalent to ignoring all digits beyond millisecond precision.
> 
> 
> Also reported to test262 for coverage:
> https://github.com/tc39/test262/issues/3437

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220321/406116d1/attachment.htm>