Description

Though Zend_Date claims to solve the 2038 issue, when I do:

$date = new Zend_Date();
$date->addMonth(350);

I get a date in 1970.

With my limited knowledge of the ZF internals I tracked this down to Zend_Date_DateObject in the (internal) function mktime() where a check is made on $year being between 1901 and 2038. But with months > 12 this would not be the right check resulting in the native mktime() function receiving a date > 2038.

Sorry to have left this so long, on my system (Ubuntu 11.04, PHP Version 5.3.5-1ubuntu7.2, ZF 1.11.10) this test does not pass. There I was stuck, but looking at the below snippet of the internal mktime function of Zend_Date_DateObject I understand my negative result:

This checks for the $year argument but not for the total result of adding months, $years and the other arguments. Unless I miss some subtilities in other parts of the code, this is clearly a bug imho.

E.g. php mktime(0,0,0,350,0,2011) returns false on my system - as does mktime(0,0,0,11,0,2038) but not mktime(0,0,0,1,0,2038) - but these arguments pass the test to qualify for the internal php mktime in the function above. This would not be noticed in most cases because either the year needs to be close to 2038 or the number of months needs to be equivalent to a large number of years, as in my case (I use Zend_Date for actuarial calculations where these extreme cases are not unusual).