« Return to Thread: Date.prototype.toISOString and Invalid Date
Re: Date.prototype.toISOString and Invalid Date
by Brendan Eich-3
::
Rate this Message:
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@...]
>> Sent: Wednesday, June 10, 2009 9:42 AM
>> To: Allen Wirfs-Brock
>> Cc: John Cowan; Adam Peller; es-discuss@...; es5-
>> discuss@...
>> 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
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
> 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@...]
>> Sent: Wednesday, June 10, 2009 9:42 AM
>> To: Allen Wirfs-Brock
>> Cc: John Cowan; Adam Peller; es-discuss@...; es5-
>> discuss@...
>> 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
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
« Return to Thread: Date.prototype.toISOString and Invalid Date
| Free embeddable forum powered by Nabble | Forum Help |
