Date format not respected in LessThan and GreaterThan validators #4440

maxnuf opened this Issue May 7, 2013 · 11 comments


None yet

8 participants

maxnuf commented May 7, 2013

The date format of form elements are not taken into account when a form is validated with min and max attribute. This is because the LessThan and GreaterThan validators compare strings.

When I set the format for my Date element to 'd-m-Y' and set max attribute to "01-01-2001"
my input "10-01-2000" will return an error:

10-01-2000 < 01-01-2001 returns false

DASPRiD commented May 7, 2013

Those validators are not meant for date comparisons.

@DASPRiD DASPRiD closed this May 7, 2013
maxnuf commented May 8, 2013

Exactly. But they are used inside /Zend/Form/Element/DateTime as validators:

DASPRiD commented May 8, 2013

Oh, that is clearly a bug then.

@DASPRiD DASPRiD reopened this May 8, 2013

This is a hard one, as the return value of getValue() is what is passed to the validator chain. Since by default, that's the formatted string, comparisons will likely not work as expected; ideally, we should be comparing the timestamps.

The only way I can think of to manage this is to create a custom Input type for date and/or time types which will ensure the timestamp is used. However, this will also likely require changes to the various date and time elements so that getValue() returns a DateTime object.

As such, I'm postponing the issue to 2.3.0, as we need time to work out a reasonable solution.


Possibly related to #4510 (comment).


Releated: #4887


Doing a little more investigation today. More problematic than expected:

  • getValue() can return any of: a DataTime instance, a formatted date/time string, or a timestamp.
  • As a form element, the likelihood of having a DateTime instance present is next to nil.
  • The only filter related to date/time values is Zend\Filter\DateTimeFormatter, which will cast the value to a string, based on the format registered with it.

About the only way I see this working at this point is if you do one of the following:

  • Right now, if you specify a format for the element of "u" or "U", and also add a DateTimeFormatter filter for the element that uses that format, the current validators should "just work," as they will be comparing integer strings.
  • As for a future fix, we could add the DateTimeFormatter filter by default to the input specification, using the same format string as is registered with the element. This would attempt to munge the value into a formatted date/time string. This would only work for comparison purposes if using the "u" or "U" formats, however.
  • Alternately, we could add Form-specific validators that would cast the values to DateTime instances before doing the necessary >, <, and step validations, but ultimately leave the value of the input untouched. This seems more tricky, but probably more correct.

Eventually, we will want to make GreaterThan and LessThan work with DateTime and other built-ins. However, I think the crux of the problem, as reported here, has more to do with the DateTime form element, and requires a different approach, as outlined above.

@maxnuf @localheinz @ThaDafinser @DASPRiD -- thoughts?

maxnuf commented Mar 6, 2014

Using the DateTimeFormatter does help, but only for the date formats that the \DateTime parser understands. mm-dd-yyyy won't work.

I think an EarlierThan and LaterThan Validator that cast values to DateTime based on a specified format is a more clear approach.


Postponing to 2.4.0, as this will require a fair number of additions and changes to accomplish.

@weierophinney weierophinney modified the milestone: 2.4.0, 2.3.0 Mar 10, 2014
Ocramius commented Jan 3, 2015

Removing milestone, as nobody provided a PR for this issue so far.

@Ocramius Ocramius removed this from the 2.4.0 milestone Jan 3, 2015
@Maks3w Maks3w added Validator and removed InputFilter labels Sep 4, 2015
@GeeH GeeH added the To Be Closed label Mar 5, 2016
GeeH commented Jun 27, 2016

This issue has been closed as part of the bug migration program as outlined here -

@GeeH GeeH closed this Jun 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment