isISO8601 strict mode bug: it fails if month and day are both 2 digits

[natesilva]

isISO8601 in strict mode fails for dates where the month and day are both 2 digits.

isISO8601('2018-11-01', { strict: true }); // true
isISO8601('2018-11-12', { strict: true }); // false!

There is a bug here: https://github.com/chriso/validator.js/blob/ef5f7a1657e4ea2a716c323b1e8f0bb0f0b79dd0/src/lib/isISO8601.js#L26

If either the month or day are a number less than 10, then it passes a string to the Date constructor like this: 2018-11-1 (note no leading 0 for the day). If both are two digits, then it passes something like this: 2018-11-12.

• In the first case (the month or day are 1 digit), Node/Chrome interprets the date as being midnight in the local timezone.
• If both month and day are 2 digits, Node/Chrome interprets the date as being midnight in UTC.
• Firefox 63 treats both as UTC.
• Safari 12 rejects the first one.

The lines following that one use getFullYear, getMonth, and getDate which work using the local timezone. Therefore it works (on Node/Chrome) if either the month or day are 1 digit.

• All of the previous regression tests used dates where either the month or day was 1 digit. Since the tests run on Node, they passed.

The solution is to always build the date using 2 digit month/day values, with a leading 0 if necessary. This ensures the date will be interpreted as being in UTC.

Then, use the UTC functions getUTCFullYear, getUTCMonth, and getUTCDate in the comparison.

[chriso]

Good catch, and thanks for the detailed write-up.