`Date.parse` and `Date::toISOString` produce possibly invalid results for extended years

[Kit Cambridge]

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() == "[phone]T00: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.

[Gavin Barraclough]

From the spec for Date.parse (15.9.4.2):
    "The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats."

The more lax parsing is both permitted by the spec, and likely necessary for web compatibility.

However for Date.prototype.toISOString (15.9.5.43):
    "This function returns a String value represent the instance in time represented by this Date object. The format of the String is the Date Time string format defined in 15.9.1.15."

Looks like the result of toISOString should comply with 15.9.1.15, seems like this may well be a bug.

[Gavin Barraclough]

*** This bug has been marked as a duplicate of bug 63986 ***

[Gavin Barraclough]

Our Date.parse behavior is valid (ES5 permits implementation specific fallback for the standard parsing), the toISOString issue identified was a real bug, but was fixed by the duped bug!