Adding moment.fn.isValid

[timrwood]

Not ready to be pulled in yet, just wanted to open the discussion.

[timrwood]

Right now, ISO8601, array, and string from format(s) all run through the internal function dateFromArray(input, asUTC). See the function here

The way I intend to check date validity is by comparing the input array to an array constructed from the date getters. I might as well expose the method on the prototype as moment.fn.toArray.

If the string was just parsed as a string like in Date.parse(), it should also fail on the line with return !isNaN(this._d.getTime());

@rockymeza and @nailor what do you guys think about this? I need to add some more unit tests before pulling this in for future regressions, but I think it's pretty solid.

[rockymeza]

What is the use case for this again?

[timrwood]

This is to address #235. The main use case would be validating user input.

var input = moment($('#datepicker').val(), 'MM-DD-YYYY');
if (input.isValid()) {
    // do something
} else {
    alert("Thats not a date silly...");
}

[timrwood]

Note: This will not work after manipulating the moment as it compares the current array of date parts against the one that was used to create the date.

var a = moment([2010, 0, 1]);
a.isValid(); // true
a.add('months', 1);
a.isValid(); // false

Other than that, I think this is ready to merge in. @nailor, want to weigh in as you opened the issue that warranted this change?

[nailor]

Looks good to me :)

[rockymeza]

That it ceases to be valid after manipulation is a bit odd. But I think that the major use case is supposed to be right after instantiation, not after manipulation. We should document that, or maybe change the behavior after instantiation?

[timrwood]

The reason I wanted to avoid checking at instantiation was to avoid a performance hit on all moments.

The way we determine if a moment is valid is by checking if the date is Invalid Date or by comparing the input array to the generated array after creation. Comparing array is used with moments created with an array as well as moments created with a string and format (including the automatic iso8601 parsing).

So the two ways to check for validity are to check when the moment is created, or check the first time isValid is called.

// add to the instantiation
function Moment(date) {
    ...
    // this is added to every moment() call
    this.isValid = true;
    if (isEqualArray(originalArray, this.toArray())) {
        this.isValid = false;
    }
}
// add on first call
function Moment(date) {
    ...
    this.originalArray = originalArray;
}
Moment.prototype.isValid = function() {
    if (isEqualArray(this.originalArray, this.toArray())) {
        return false;
    }
    return true;
}

I guess I should do a jsperf on the actual impact of checking during instantiation before making a decision though.

I'm not sure of the use case where someone would want to check the validity of a moment after they have modified it. There isn't really any way to right now, as all manipulation methods can overflow, so there would never be an invalid date that was modified.

[timrwood]

Here are the jsperf results. http://jsperf.com/momentjs-validation

If we make it so that isValid will work even after modifying the moment, it will cut performance in half for any moment created.