improves documentation for isDate()

[tacomanator]

Was confused by the docs which said isDate takes a string. Took some time to figure out correct way. Hoping this helps others avoid that.

[chriso]

It does take a string! The library validates strings only, and your dates are being coerced to a string before validation:

> new Date(2015, 1, 26).toString()
'Thu Feb 26 2015 00:00:00 GMT+0900 (JST)'

The date validator is fairly lenient which may be the cause of confusion (#476). Can you provide some examples that you found confusing?

[tacomanator]

@chriso I see that I didn't investigate enough. My expectation was that isDate would accept any string that works with new Date(). However I ran into the following problem:

 > new Date('2011-12-21')
<· Tue Dec 20 2011 16:00:00 GMT-0800 (PST)

 > isDate('2011-12-21')
<· false

 > isDate(new Date('2011-12-21'))
<· true

While looking into it I found #476, which says to use toDate on strings before passing them to isDate. This worked for the above date, so I made a bad assumption.

 > isDate(toDate('2011-12-21'))
<· true

Is it supposed to be that isDate only accepts strings in the format output by date.toString()?

[chriso]

As noted in #476, the isDate validator uses the built-in Date.parse() function which is very lenient. If Date.parse(str) returns something other than NaN then the validator attempts to filter out invalid dates such as 2015-02-29:

> validator.isDate('2011-12-21')
true
> validator.isDate('2015-02-29')
false

The fact that your validator.isDate('2011-12-21') is returning false is a bug, probably timezone related (#472, #431). What version are you using and what's the result of new Date().getTimezoneOffset() for you? Do any of the unit tests fail (npm test)?

[tacomanator]

@chriso Version is 4.5.1

> new Date().getTimezoneOffset()
480

One test fails:

  77 passing (256ms)
  1 failing

  1) Validators should validate dates:
     Error: validator.isDate(2011-09-30) failed but should have passed
      at test/validators.js:19:23
      at Array.forEach (native)
      at test (test/validators.js:14:23)
      at Context.<anonymous> (test/validators.js:892:9)

The same input fails in the browser. Here's a screenshot of the inspector:

[chriso]

Thanks. Would you mind applying the following diff and the re-running the tests?

diff --git i/validator.js w/validator.js
index 900e718..cd3b777 100644
--- i/validator.js
+++ w/validator.js
@@ -522,7 +522,8 @@
         } else {
             timezone = iso8601Parts[21];
             if (!timezone) {
-                return null;
+                // if no hour/minute was provided, the date is GMT
+                return !iso8601Parts[12] ? 0 : null;
             }
             if (timezone === 'z' || timezone === 'Z') {
                 return 0;

The following two dates are both valid ISO8601 dates, but Date.parse() parses the first in the user's timezone and the second in GMT:

> new Date('2015-01-01 12:00')
Thu Jan 01 2015 12:00:00 GMT+0900 (JST)
> new Date('2015-01-01')
Thu Jan 01 2015 09:00:00 GMT+0900 (JST)

[tacomanator]

@chriso tests pass with the patch

[chriso]

Thanks. I've published the fix in 4.5.2. Did you have any other issues/inconsistencies with the validator?

[tacomanator]

Thanks I'll grab the new version and let you know if I run into any other issues :)

[chriso]

Awesome, thanks!