Rationale behind supporting "Invalid Date"
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 18.104.22.168 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.
>> 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
More information about the es-discuss