[Webkit-unassigned] [Bug 238050] New: [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

            Bug ID: 238050
           Summary: [JSC] Change Date.parse to stop returning numbers with
                    fractional part
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: richard.gibson at gmail.com

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)

#### 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).

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/20220317/ff4d3149/attachment.htm>