Date.prototype.toISOString and Invalid Date

Brendan Eich 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 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: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.
>>
>> /be
>>
>



More information about the es-discuss mailing list