[Webkit-unassigned] [Bug 69231] New: `Date.parse` and `Date::toISOString` produce possibly invalid results for extended years

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Oct 2 17:13:19 PDT 2011


           Summary: `Date.parse` and `Date::toISOString` produce possibly
                    invalid results for extended years
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Minor
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: kitcambridge at gmail.com

In the latest WebKit nightly, `Date.parse` and `Date::toISOString` produce the following results for extended years:

    // January 1st, 1 B.C.
    var value = -62198755200000;
    new Date(value).toISOString() == "-001-01-01T00:00:00.000Z";
    Date.parse("-001-01-01T00:00:00.000Z") == value;

    // September 13th, 275760 A.D.
    value = 8.64e15;
    new Date(value).toISOString() == "275760-09-13T00:00:00.000Z";
    Date.parse("275760-09-13T00:00:00.000Z") == value;

Both results differ from the simplified date time string format specified in ES 5.1 section, which directs that years be Gregorian decimal digits between 0000 and 9999. Although specifies an extended year format, which comprises a `+` or `-` sign followed by 6 digits, the string produced by `Date::toISOString` conforms to neither format. Likewise, according to my interpretation of the spec, `Date.parse` shouldn't parse the provided string according to the specified format in

The expected results are:

    new Date(-62198755200000).toISOString() == "-000001-01-01T00:00:00.000Z"
    Date.parse("-001-01-01T00:00:00.000Z"); // => `NaN` or an implementation-specific result as per

    new Date(8.64e15).toISOString() == "+275760-09-13T00:00:00.000Z";
    Date.parse("275760-09-13T00:00:00.000Z"; // => `NaN` or an implementation-specific result.

However, the fact that the questionable behavior also exists in Firefox 6.1 suggests that WebKit's current implementation is, in fact, spec compliant.

I would be grateful if any WebKit developers could elucidate if this is a legitimate bug or not.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list