123 incorrectly accepted as valid date

[parf02]

Subject of the issue

if validate date and enter 123 it says its a valid date

Your environment

v1.11.0

Steps to reproduce

http://jsfiddle.net/Ls3kqfu6/
this is for abc which is incorrect
if enter 123 it will be correct

Expected behaviour

should not accept 123 as date

Actual behaviour

accepts 123 as date

[staabm]

Does the issue also happen on the lastest 1.15 release?

[Arkni]

That's not a bug, as the date method relies on the Date constructor to test for valid dates. So 123 is valid because new Date(123).toString() yields Thu Jan 01 1970 00:00:00 GMT+0000 (WET) which is a valid date, though.

If you take a look at date method docs, you will notice this recommendation:

This method should not be used, since it relies on the new Date constructor, which behaves very differently across browsers and locales. Use dateISO instead or one of the locale specific methods (in localizations/ and additional-methods.js).

[staabm]

I guess we should mark it as deprecated in the sources

[Arkni]

Yeah, and should be removed in @2.0. Also, we can add a warning msg to inform the user that this method should not be used, and suggest alternatives.

[joepagan]

If this is not recommended, could it be turned off by default? I know you wish to remove eventually, though it seems a bit odd to have it on by default.

For those who want to turn it off, in a rules object:

'field': {
  required: true,
  date: false
},

[Arkni]

@joepagan

I'm afraid disabling the date validator by default is not an option right now, as there are developers that replace it with their own validator, and we can't afford to disable their own code without prior notice.

I think for now, we only need to print a warning whenever this method is used.

[joepagan]

I think a developer who upgrades a package to a new version without reading a changelog is the one at fault.

I don't think you should worry about that, though of course it is up to you!

Many thanks for jquery-validation btw.

[Arkni]

Our pleasure :)

[staabm]

I think for now, we only need to print a warning whenever this method is used.

👍

[stale]

This issue/proposal has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and one of the maintainers will (try!) to follow up.
Thank you for contributing :)

[kousu]

I just ran into this. There's a nasty interaction with min/max: if you have a form entry like

<input id="birthdate" name="birthdate" type="date" min="1900-01-01" max="2000-01-10">

then the plugin generates this rule:

"birthdate": {date: true, min: NaN, max: NaN}

which always fails to validate.

The workaround I found was to specify this rule instead:

"birthdate": {
          dateISO: true,
          // *disable* the old half-broken date validator 
          // see https://github.com/jquery-validation/jquery-validation/issues/1787 
          date: false, 
          min: false, 
          max: false 
        }

Without explicitly setting those parameters to false, the plugin fills them in with NaN by default and .rules("remove", "min max") doesn't seem to work to get rid of them.

I hope this workaround helps someone else, or maybe can be integrated into the codebase.