Rationale behind supporting "Invalid Date"

[Allen Wirfs-Brock]

On Feb 12, 2012, at 3:02 PM, Brendan Eich wrote:

> Andrew Paprocki wrote:
>> On Sat, Feb 11, 2012 at 8:32 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>>> It's well-specified by 15.9.3.1 etc.
>> 
>> I was reading http://es5.github.com/x15.9.html and I see the spec for
>> allowing NaN as the "this time value". Where did the "Invalid Date"
>> toString() came from?
> 
> toString is underspeicified but it seems implementations all agree -- when the Date instance's time value is NaN, "Invalid Date".
> 
>> I don't see it on that page at all, yet all the
>> browsers seem to return it.
> 
> We could spec this, FWIW. Not a big deal.

now https://bugs.ecmascript.org/show_bug.cgi?id=268 


>> 
>> I was thinking of trying it out when running in a "debug" mode to help
>> catch errors. Is there any actual real use in the wild for a Date with
>> a NaN value?
> 
> Not sure. Probably, since it goes back 16 years. No one is inclined to find out the hard way, I bet. We could add throwing as a strict mode behavior but then we are enlarging strict mode from what it is today in shipping browsers.


I would expect that this, 
   isNaN(new Date(Date.parse(someString)))
or an equivalent formulation occurs someplace on the web as a check for validity of date strings.  The constructor call is not really necessary in this case but that doesn't mean that someone hasn't written code exactly like this.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120214/be3dc742/attachment.html>