Rationale behind supporting "Invalid Date"
It's well-specified by 15.9.3.1 etc.
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:
var Date = function (origDate) { "use strict"; return function Date() { if (!(this instanceof Date)) { // Approximate test for called-as-function, use apply. return origDate.apply(this, arguments); }
var args = [].slice.apply(arguments);
args.unshift(this);
var ctor = origDate.bind.apply(origDate, args);
var date = new ctor;
var time = date.getTime();
if (time !== time) {
throw 'Invalid Date';
}
return date;
}; }(this.Date);
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 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?
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.
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 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
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 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 ecmascript#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.
I'm wondering if someone can point me to any past rationale for the decision to support Date objects in an "Invalid Date" state instead of throwing an exception whenever the user attempts to form an invalid date?
Tracking down the source of script errors is difficult if something like "new Date(undefined)" is done, followed by a ".getTime()", propagating a NaN down layers of abstraction. Additional strange cases involve using NaN, Infinity, etc throughout the Date API.
I was curious if there is a good reason for this or if potentially undefined / non-finite numbers could throw in a strict-mode setting. I didn't notice this behavior in the spec, but all browsers appear to follow the same convention.