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

[bugzilla-daemon at webkit.org]

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

           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 15.9.1.15, which directs that years be Gregorian decimal digits between 0000 and 9999. Although 15.9.1.15.1 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 15.9.1.15.

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 15.9.4.2

    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.