On Jun 10, 2009, at 11:00 AM, Allen Wirfs-Brock wrote:
This would also imply that (new Date(NaN).toJSON()) also throws. Is
everybody fine with that??
Too much of the cheese-whiz that is still dried up and stuck to the
language from 1995 (JS in Netscape 2) or 1997 (ES1 in Ecma) came about
because of lack of try/catch. Read-only assignment was a fail-stop
error condition in Netscape 2 if memory serves, but this was
considered too harsh without try/catch, so ES1 went with silent but
deadly failure to update.
In the modern world, when you can't encoding a value as an ISO string
or JSON, throwing is absolutely the right answer.
RFC 4627 says "Numeric values that cannot be represented as sequences
of digits (such as Infinity and NaN) are not permitted."
ES5 draft 15.9.5.44 Date.prototype.toJSON says "This function returns
the same string as Date.prototype.toISOString()."
Works for me.
/be
Allen
-----Original Message-----
From: Brendan Eich [mailto:[email protected]]
Sent: Wednesday, June 10, 2009 9:42 AM
To: Allen Wirfs-Brock
Cc: John Cowan; Adam Peller; [email protected]; es5-
[email protected]
Subject: Re: Date.prototype.toISOString and Invalid Date
On Jun 10, 2009, at 8:48 AM, Allen Wirfs-Brock wrote:
I believe that support for ISO dates in ES5 is intended to provide a
standard interchange format for dates, not for providing a locale
customized format for human consumption. Since ISO 8601 apparently
doesn't provide an encoding for "invalid date/time", arguably new
Date(NaN).toISOString() should never be passed to someone expecting
a valid ISO date. If that is true, then be best thing to do may be
to specify that toISOString throws a RangeError when applied to such
Date objects.
+1, or more.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
