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:
DateInterval is used for iteration. For stuff like this:
$db = new DateTime('2008-12-31');
$de = new DateTime('2009-12-31');
$di = DateInterval::createFromDateString('third tuesday of next
month');
$dp = new DatePeriod($db, $di, $de, DatePeriod::EXCLUDE_START_DATE);
foreach($dp as $dt) {
echo $dt->format("F jS\n") . "<br>\n";
}
I also disagree with your suggestion that "calendar math" is "precision
math calculations". The strtotime approach is actually the precise
approach since you never have inconsistencies like this:
mysql> SELECT DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH);
+--------------------------------------------------+
| DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH) |
+--------------------------------------------------+
| 2009-02-28 23:59:59 |
+--------------------------------------------------+
mysql> SELECT DATE_SUB('2009-02-28 23:59:59',INTERVAL 1 MONTH);
+--------------------------------------------------+
| DATE_SUB('2009-02-28 23:59:59',INTERVAL 1 MONTH) |
+--------------------------------------------------+
| 2009-01-28 23:59:59 |
+--------------------------------------------------+
So, you essentially have
$a + month = $b
$b - month != $a
Or have 2 times 24-hours apart map to the same exact timestamp when you
add a month:
mysql> SELECT DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH);
+--------------------------------------------------+
| DATE_ADD('2009-01-31 23:59:59',INTERVAL 1 MONTH) |
+--------------------------------------------------+
| 2009-02-28 23:59:59 |
+--------------------------------------------------+
mysql> SELECT DATE_ADD('2009-01-30 23:59:59',INTERVAL 1 MONTH);
+--------------------------------------------------+
| DATE_ADD('2009-01-30 23:59:59',INTERVAL 1 MONTH) |
+--------------------------------------------------+
| 2009-02-28 23:59:59 |
+--------------------------------------------------+
I understand why it works that way, but it certainly isn't ideal, nor
is it precise if you aren't expecting that. Neither way is perfect. We
chose to have all relative date operations follow the same rules.
Having Interval and Modify use different relative date rules would be
very confusing.
Previous Comments:
------------------------------------------------------------------------
[2009-08-07 00:22:37] brad at omnis dot com
Why have dateInterval at all? If you don't want to have "2
different implementations". dateTime::modify() existed prior to PHP
5.3.0 and did the job of strtotime(). All dateInterval does at this
point is to confuse anyone who thinks it may add time in a
non-GNU-strtotime way and do calendar math.
If I wanted strtotime capability with dateTime objects I could just use
dateTime::modify() could I not?
What is the issue with having dateInterval work in a calendar math way
and having dateTime::modify() work the old unix way? Both sides would
be happy.
(Also, http://bugs.php.net/bug.php?id=43999 is about strtotime
specifically. There is nothing obvious that dateInterval has anything
to do with strtotime)
------------------------------------------------------------------------
[2009-08-06 23:40:54] ras...@php.net
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.
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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
