Zend Framework

1111 is recognised as 1.1.11 -> 01. Jan.2011 and therefor true

Thomas, for what can i specify a format if it doesnt matter.
Sorry for me this makes no sense.
Maybe its ok for isDate alone, but Zend_Form_Validator_Date uses isDate for validation, and in this case this is pointless.

btw. 111 is true too, what would this be ? 01.01.0001 | 1901 | 2001 ?

I did not say that this behaviour is correct nor did I close the issue.
Actually seperators are not detected.

Regarding 111, this depends on the used format.

ddMMYY will recognise it as 01.Jan.2001
ddMMYYYY will recognise it as 01.Jan0001

sorry if my wording came out a bit rude

just to be sure i understand it correctly:

shouldnt a format of ddMM imply a string length of 4 ?

eg.
ddMM == 0108 (01.08. )
ddMM != 108 (1.08)

couse if not 112 could mean 1.12 or 11.2

the convertPhpToIsoFormat is used, which "normalize" the format string
ddMM stays untouched but dM would be transformed to ddMMM
and know it comes jM would be dMMM

the example with 112:
dM == ddMMM 11.2
ddM == ddMMM 11.2
jM == dMMM 1.12

so as i see it, the code takes the format right. if dd the day "must" have a strlen of 2, if j the day "must" have a strlen of 1

but maybe i missunderstand the whole class , would be probably better I go to bed

No, MM could also be the localized month representation (f.e. Jan).
The convertPhpToIso method is not called except you explicitly set the GNU format manually which you did not according to the given format examples.

d does not mean strlen 1, as it is not the date as string but it's the format.
d as defined by ISO means a day representation with MINIMUM one digit.
This means "1" is acceptable as also "01" or "10

But this has no information for the issue nor does it add any benefit for it.

I can't see what use the isDate function has. Thomas Weidner said on 23/Feb/09 02:48 PM in relation to ZF-5869 that "Leading and following parts are stripped". The above post alludes that virtually arbritrary numbers are recognised as dates (eg 1111 is recognised as 1.1.11 -> 01. Jan.2011).

So, isDate returns true for the string "Yesterday, I ate 1111 hamburgers"??

isDate conveniently strips the last "9" from 20090199 to produce 09.Jan.2009??

That defeats the purpose of checking a date!!

1111 is recognised as 1.1.11 -> 01. Jan.2011 and therefor true

And therefore this is a bug: 1111 is not a date, if it's recognized as such, it's wrong. (reference http://en.wikipedia.org/wiki/Calendar_date and http://de.wikipedia.org/wiki/Kalenderdatum ). My birthday is on AHEQ316; now it's for Zend_Date to recognize it the way I meant...

Is there any solution planned for this? The issue is almost a year old.

If not this issue would already have been closed as won't fix.

The problem isn't just with dates. Invalid times also pass validation.

Zend_Date::isDate('10.45', 'HH:mm'); //true
Zend_Date::isDate('1:1', 'HH:mm'); //true
Zend_Date::isDate('1045', 'HH:mm'); //true
Zend_Date::isDate('1000000045', 'HH:mm'); //true

I just had a situation where a time was entered as per the first example, which then got saved to the database as 00:00:10 (MySQL interprets 10.45 as 10.45 seconds).

On further inspection, it seems to me that the problem is with Zend_Locale_Format::getDate(), and not with Zend_Date per se.

Shouldn't fix_date being set to false prevent this from validating?

I'm having the same issue and in my oppinion this is a real problem because isDate makes no sense for me though.

My Example:

Zend_Date::isDate('0811', 'dd.MM.YYYY'); //Returns true, but false would be correct!

I'm sure that Zend_Date's validation problems will be solved in ZF2, but in the meanwhile I did a validator which solves the problems addressed here. Feel free to use it, Kblom_Validate_Datetime. It has a little bit different API than Zend_Date, but it should be useful in forms etc.