Rationale behind supporting "Invalid Date"

Brendan Eich brendan at mozilla.com
Sun Feb 12 15:02:06 PST 2012

Andrew Paprocki wrote:
> On Sat, Feb 11, 2012 at 8:32 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> It's well-specified by 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.

>> This is all based on java.util.Date from ages ago, sorry it is painful.

Norbert pointed out in private that I can't quite blame Java for this. 
Java API + JS dynamic types and double-as-number + lack of try/catch in 
ES1, more accurately.

>> Have
>> you considered wrapping Date with a user-defined function that throws if an
>> invalid Date with a NaN time-value is created? Something like this:
> 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.


More information about the es-discuss mailing list