Description: ------------ From time to time (every 11-12 calls) after() changes the date to the day before. In the testscript it looks like this: ------------ curDay: 15.09.2007 nextDay: 16.09.2007 !after: 1 still nextDay: 16.09.2007 ------------ curDay: 16.09.2007 nextDay: 17.09.2007 !after: 1 still nextDay: 16.09.2007 ------------ curDay: 16.09.2007 nextDay: 17.09.2007 !after: 1 still nextDay: 17.09.2007 I am running php on a windows machine so i can't provide any "configure line" but maybe the extension do help: gd2, mbstring, mcrypt, mssql, mysql, sockets Test script: --------------- <? include_once 'Date.php'; $date = new Date(); for($i = 0; $i < 20; $i++){ echo "------------<br>"; echo "curDay: ".$date->format("%d.%m.%Y")."<br>"; $date = $date->getNextDay(); echo "nextDay: ".$date->format("%d.%m.%Y")."<br>"; echo "!after: ".!$date->after($date)."<br>"; echo "still nextDay: ".$date->format("%d.%m.%Y")."<br>"; } ?>

The problem is in Date#compare(), it is a non-side-effect-free function, since it "normalizes" the TimeZone of both inputs to do the compare. The patch should be to use a copy of the inputs before to invoke Date#convertTZ(), or reimplement convertTZ to return a different instance. function compare($first, $second) { $d1 = new Date(); $d2 = new Date(); $d1->copy($first); $d2->copy($second); $d1->convertTZ(new Date_TimeZone('UTC')); $d2->convertTZ(new Date_TimeZone('UTC')); ... }

Fixed

Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at http://pear.php.net/get/Date