Date.prototype.toISOString and Invalid Date
brendan at mozilla.com
Wed Jun 10 11:07:06 PDT 2009
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 220.127.116.11 Date.prototype.toJSON says "This function returns
the same string as Date.prototype.toISOString()."
Works for me.
>> -----Original Message-----
>> From: Brendan Eich [mailto:brendan at mozilla.com]
>> Sent: Wednesday, June 10, 2009 9:42 AM
>> To: Allen Wirfs-Brock
>> Cc: John Cowan; Adam Peller; es-discuss at mozilla.org; es5-
>> discuss at mozilla.org
>> 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.
More information about the es-discuss