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 channel. On Sun, Feb 12, 2012 at 10:49 AM, Andrew Paprocki <[email protected]>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? 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. > 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? > > -Andrew > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
