730831 - Date.prototype.toISOString returns not a valid ISO-8601 string

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[André Bargull [:anba]]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

js> new Date("+020000-01-01T00:00:00.000Z").toISOString()



Actual results:

SM returns the string "20000-01-01T00:00:00.000Z"


Expected results:

toISOString() should return a valid ISO-8601 Extended Format string with expanded years representation. But also see https://bugs.ecmascript.org/show_bug.cgi?id=119 about the current under-specification of toISOString().

Comment 2

[[e-mail]]

Same here.

toISOString is not using Extended Format for years outside 0000..9999.

I.e. not using signed 6-digit extended years,
according to ES5 spec section 15.9.1.15.1

Comment 3

[Helder "Lthere" Magalhães]

Marking as 'new' due to the already confirmed cases and my own.

When trying to understand why the JSON3 [1] library partially "failed" in Firefox, falling-back to a script-based implementation for the 'stringify' part (the 'parse' seems to be properly working, though), I noticed that the particular test [2] (here simplified) which made the correctness of the API fail was similar to:

var stringifySupported = JSON.stringify(new Date(8.64e15)) == '"[phone]T00:00:00.000Z"';

This causes Firefox to serialize the date as "275760-09-13T00:00:00.000Z", thereby missing the positive sign, which is mandatory in extended years according to ES5.1 - 15.9.1.15.1 [3]. (On the other hand, negative extended dates seem to be properly working in this scope.)

This is somehow annoying as this library usage seems to be increasing and also because it's a valid correctness test which is failing with a reason.

Finally, for strict web services which start to adopt this "new" format for Date object serializing into JSON, this issue may cause content including extended years (which are arguably rare, but that's my experience) to be discarded for this reason.

As a side note, the under-specification of 'toISOString' issue, stated in comment #0, is already addressed and properly marked as "fixed".

[1] https://github.com/bestiejs/json3
[2] https://github.com/bestiejs/json3/blob/gh-pages/lib/json3.js#L139
[3] http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.3

Comment 4

[Helder "Lthere" Magalhães]

(Adding link to relevant issue created for JSON3 to "See Also" field in the scope of comment #3.)

Comment 6

[André Bargull [:anba]]

Attachment: bug730831_Date_toISO_extended.patch

Use ISO-8601 extended year format when the year is before 0 resp. after 9999 [1, 2].

[1] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-extended-years
[2] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-date.prototype.toisostring

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8511648 [details] [diff] [review]
bug730831_Date_toISO_extended.patch

I'm not a JS peer, sorry.

Comment 8

[Jason Orendorff [:jorendorff]]

Comment on attachment 8511648 [details] [diff] [review]
bug730831_Date_toISO_extended.patch

Review of attachment 8511648 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks again!

Comment 9

[Helder "Lthere" Magalhães]

Pinging as a positively reviewed patch is available for a trimester already, so (apparently) no reason for leaving this issue open...? ;-)

Comment 10

[Till Schneidereit [:till]]

Attachment: Updated draft rev + reviewer

Pushed to try here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4874745e2c81

Thanks for the ping, Lthere.

Comment 11

[Till Schneidereit [:till]]

Preemptively setting checkin-needed as I don't see why this should fail.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6e36a128e1c5

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6e36a128e1c5