Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leap year and general date validation for isDate() #418

Merged
merged 1 commit into from
Aug 15, 2015

Conversation

ravestack
Copy link
Contributor

Let me know if you'd like me to add comments for anything in particular or if I should break this out into a separate function.

@@ -450,7 +450,26 @@
};

validator.isDate = function (str) {
return !isNaN(Date.parse(str));
var rawDate = new Date(str);
var normalizedDate = new Date(rawDate.getTime() + rawDate.getTimezoneOffset()*60000);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why add rawDate.getTimezoneOffset() * 60000 here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A valid Date object like new Date('2011-09-30') could be interpreted differently depending on the javascript engine.

In webkit browsers and node.js, this returns Thu Sep 29 2011 20:00:00 GMT-0400 (EDT)
whereas in Firefox, this returns 2011-09-30 T00:00:00.000Z. I.e., different days are interpreted. Adding getTimezoneOffset() * 60000 standardizes the date.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I was wondering more about the 60000 but I see now that getTimezoneOffset() returns an offset in minutes.

@ravestack
Copy link
Contributor Author

Added more tests and slightly modified the date matching regex.

, '2011-08-04 12:00'
, '2/29/24'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test fails for me in UTC+1. rawDate is equal to Thu Feb 29 2024 00:00:00 GMT+0100 (CET) and normalizedDate is equal to Wed Feb 28 2024 23:00:00 GMT+0100 (CET).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I realized I've been doing date normalization the wrong way. There's built-in functions that use the UTC date. I've switch to using those. Tests should pass now.

Also, let me know if you'd like me to squash my commits.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks. Yeah that'd be great if you could squash them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

squashed

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test is still failing for me. normalizedDate is equal to Thu Feb 29 2024 00:00:00 GMT+0100 (CET) and so getUTCDate() returns 28. All tests pass if I change getUTCDate() to getDate().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. Tests fail for me if I switch to getDate(). I'll look at this later today.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still looking at this. I'll send out a diff soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chriso Just updated the diff. It should work now. I tested it in over 15 time zones.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks!

chriso added a commit that referenced this pull request Aug 15, 2015
Leap year and general date validation for isDate()
@chriso chriso merged commit cc7071f into validatorjs:master Aug 15, 2015
@chriso chriso mentioned this pull request Aug 17, 2015
@chriso
Copy link
Collaborator

chriso commented Aug 17, 2015

@ravestack I had to revert this one as it what causing invalid results when the date string had hours, minutes or seconds that started with a 2 or 3. If you can fix up those issues I'd be happy to accept another PR.

@ravestack
Copy link
Contributor Author

@chriso really sorry about that. I'll be sure to make an extensive test suite this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants