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:
Well, it uses the same strtotime code. We are not going to have 2 different implementations here. I have no difficulty understanding that some people might expect database-like behaviour, But at the same time, there are also people who expect UNIX-like behaviour. You seem to be discounting those, and in the end we had to choose one or the other. And the reason it was marked bogus was because it had been filed before. A quick search finds the previous bugs easily. Previous Comments: ------------------------------------------------------------------------ [2009-08-06 22:53:57] brad at omnis dot com Notice I'm not complaining about the dateTime::modify() function, which explicitly states it uses strtotime() format. I'm taking about a function that explicitly states "Adds an amount of days, months, years, hours, minutes and seconds to a DateTime object", I'm not making any claim that you "made this stuff up". I would argue that the GNU guys got it wrong (see the example of how databases handle it for an alternate point of view), but that's not the issue. I'm talking about PHP here, not GNU. What is so difficult to understand that people using these sets of functions might expect that it works in the same manner that databases do. I've been using PHP for 10+ years, I'm not trying to make you mad, I'm trying to help make PHP better by filing bug reports, and what do I get in response to a legitimate issue? I get it marked as BOGUS. A compromise of making the dateInterval constructor have a "[, bool $calendarMath]" (or a bitmask) option would be welcome, but leaving it as is, I believe will lead to confusion and headache for those wishing to use these functions for anything that requires precision math calculations. ------------------------------------------------------------------------ [2009-08-06 22:32:25] ras...@php.net 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48824 -- Edit this bug report at http://bugs.php.net/?id=48824&edit=1
