Rationale behind supporting "Invalid Date"
Mark S. Miller
erights at google.com
Sun Feb 12 13:36:02 PST 2012
If the Date.prototype continues to be a valid Date object, which would be
unfortunate, it should at least be a valid Date object representing an
invalid unsettable date. I believe this is already what IE10 does.
The invalidity isn't really necessary. What is necessary is that the
internal Date representation of this special object be unsettable, since it
cannot be made unsettable simply by freezing this object. Better would be
to reform our pattern that a built-in Foo.prototype is a valid Foo object,
with all the internal properties associated with a Foo, even though !(new
Foo() instanceof Foo). Fortunately, of the existing built-in primordials,
it is only for Date that this creates an unpluggable global communications
On Sun, Feb 12, 2012 at 10:49 AM, Andrew Paprocki <andrew at ishiboo.com>wrote:
> On Sat, Feb 11, 2012 at 8:32 PM, Brendan Eich <brendan at mozilla.com> wrote:
> > It's well-specified by 220.127.116.11 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? I don't see it on that page at all, yet all the
> browsers seem to return it.
> > This is all based on java.util.Date from ages ago, sorry it is painful.
> > you considered wrapping Date with a user-defined function that throws if
> > 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?
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss