Rationale behind supporting "Invalid Date"
Allen Wirfs-Brock
allen at wirfs-brock.com
Tue Feb 14 10:46:24 PST 2012
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>
More information about the es-discuss
mailing list