Andrew Paprocki wrote:
On Sat, Feb 11, 2012 at 8:32 PM, Brendan Eich<[email protected]> 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.
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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
