ID: 48824 Updated by: ras...@php.net Reported By: brad at omnis dot com Status: Bogus Bug Type: Date/time related Operating System: Linux (CentOS 5.3) PHP Version: 5.3.0 New Comment:
We didn't make this stuff up. We followed the GNU strtotime implementation. And it isn't as cut and dry as you make it sound that shrinking the interval is the right approach when you are at the end of the month and the next month is shorter. Given the complexity of this stuff, we figured following traditional UNIX practice would make the most sense. You can read about it here: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC114 And if you read this section: http://www.gnu.org/software/tar/manual/html_chapter/Date-input-formats.html#SEC120 They even specifically mention this case: "The fuzz in units can cause problems with relative items. For example, ‘2003-07-31 -1 month’ might evaluate to 2003-07-01, because 2003-06-31 is an invalid date. To determine the previous month more reliably, you can ask for the month before the 15th of the current month. " So, can we drop this "The PHP Devs don't want to write correct code" ranting please, and recognize that you simply don't agree with our choice. It has nothing to do with correctness. Your shell's date command behaves exactly the same way, as does any other UNIX command that uses relative dates. Previous Comments: ------------------------------------------------------------------------ [2009-08-06 18:17:24] brad at omnis dot com Just to be clear, because the PHP devs don't want to write correct code and would rather rely on a broken library, this bug gets marked as bogus and everyone has to deal with an inferior date function. To point out that my idea of date math is not incorrect, here is postgresql (also tested in MySQL and Oracle which provide the same results): query: select '01-31-2009 23:59:59'::timestamp + '1 month'::interval result: 2009-02-28T23:59:59 ------------------------------------------------------------------------ [2009-08-06 13:35:24] j...@php.net DateInterval uses the same parser as strtotime(). ------------------------------------------------------------------------ [2009-07-07 16:56:59] brad at omnis dot com >From a brief reading of the source code, dateTime->add() doesn't *appear* use the underlying strtotime library, so I don't see why this function should be forced to have the same weakness of that function. IMO, these date functions would be far more useful if they adhere to common date manipulation ideals instead of using simple math as they are currently doing. As it stands now, the dateTime->add() function cannot be relied upon for any sort of accounting math and IMO completely defeats the purpose of specialized dateTime functions. ------------------------------------------------------------------------ [2009-07-07 09:50:48] sjoerd-php at linuxonly dot nl Thank you for your report. The issue you report is not a bug. See also bug #43999. ------------------------------------------------------------------------ [2009-07-06 22:24:39] brad at omnis dot com Description: ------------ dateTime->add(dateInterval) isn't applying proper calendar math when adding intervals. Reproduce code: --------------- $dateTest = new dateTime('2008-01-31',new dateTimeZone("GMT")); print_r($dateTest); $dateTest->add(new dateInterval('P1M')); print_r($dateTest); Expected result: ---------------- DateTime Object ( [date] => 2008-01-31 00:00:00 [timezone_type] => 3 [timezone] => UTC ) DateTime Object ( [date] => 2008-02-28 00:00:00 [timezone_type] => 3 [timezone] => UTC ) Actual result: -------------- DateTime Object ( [date] => 2008-01-31 00:00:00 [timezone_type] => 3 [timezone] => UTC ) DateTime Object ( [date] => 2008-03-02 00:00:00 [timezone_type] => 3 [timezone] => UTC ) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=48824&edit=1
