Thank you for your report.

The issue you report is not a bug. See also bug #43999.

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.

DateInterval uses the same parser as strtotime(). 

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

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.

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.

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.

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)

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.

Let me start off by saying "Calendar Math != Numeric Math".  Lets get that clear.  Calendars are messy (i.e. 60m = 1h, 24h = 1d, leap seconds, leap years, etc) and things don't always back out as you might wish they would.  Your examples are EXACTLY what I would expect them to do when asking a computer to do that type of math you've given to it to do.  You also have to ask the question, what would a human operator expect from adding +1 month to January 31st.  Everyone I have spoken with agrees that it should be February and not March.

"DateInterval is used for iteration." In your opinion.  Last I checked PHP is used by more persons than just yourself.  If this language were only used by PHP Devs then we would not be having this discussion.  For your example of the usage of DateInterval I think it's great, but that does not mean that my usage is somehow invalid.

My first inclination when I saw the new functions, was "Great!  I hope these new functions are calendar based date math in PHP instead of numeric math based."

My "precision math" comment should have said "accurate math", bad choice of words on my part, but the point is still valid.  I would challenge you to find a single person, who doesn't have a  predisposition to UNIX date semantics, who would agree that adding 1 month to January 31st should result in a date in March.

Further, have you or any other PHP dev written PHP code that used strtotime("+1 month") where it would be acceptable to have January 31st + 1 month = March?  Because after lots of thought, I can not come up with a single example of where I would find that acceptable.

I don't see what the opposition to having another way of doing the date calculation is.  As it is right now, I guarantee you that standard php date functions are inadequate for use in any sort of billing/accounting systems without additional modification to handle their shortcomings.

I am obviously not the only person to request this functionality since there are numerous bug reports on the issue.  What is the opposition to giving those users the choice of how to deal with date math?

Here are examples of how other scripting languages that compete with PHP do it (hint they ALL have ways to achieve the results I expect):

::::::::::::::
java: datetest.java
::::::::::::::
import java.util.Date;
import java.util.Calendar;
import java.text.SimpleDateFormat;
import java.util.*;


class datetest { 
        public static void main(String args[]) { 

                SimpleDateFormat formatter = new SimpleDateFormat("E yyyy.MM.dd 'at' hh:mm:ss a zzz");

                Calendar rightNow = Calendar.getInstance();
                rightNow.set(2009,0,31);

                System.out.println( formatter.format(rightNow.getTime())); 

                rightNow.add(Calendar.MONTH,+ 1);
                
                System.out.println(formatter.format(rightNow.getTime())); 

        } 
}
::::::::::::::
perl: datetest.pl
::::::::::::::
use DateTime;
use DateTime::Duration;

my $date = DateTime->new(
  year      =>    2009,
  month     =>      1,
  day       =>      31,
  locale    => 'en_US',
);

my $duration = DateTime::Duration->new(
  months        =>          1,
  end_of_month  => 'preserve',
);

$date->add( $duration );  # One month more
print $date->mdy('/');    # And show it


::::::::::::::
python: datetest.py
::::::::::::::
from datetime import *; from dateutil.relativedelta import *
import calendar

print date(2009,1,31)+relativedelta(months=+1)

::::::::::::::
ruby: datetest.rb
::::::::::::::
require 'date'
d1 = Date.new(y=2009,m=1,d=31)
puts d1
d2 = (d1 >> 1)
puts d2

Also c#:

-----------------------
using System;
class Program
{   
    static void Main()
    {
        int year = 2009;
        int month = 1;
        int day = 31;
        DateTime MyDate = new DateTime(year, month, day);

        Console.WriteLine(MyDate.Month + "/" + MyDate.Day + "/" + MyDate.Year);
        MyDate = MyDate.AddMonths(1);
        Console.WriteLine(MyDate.Month + "/" + MyDate.Day + "/" + MyDate.Year);
    }
}
-----------------------

So, any change in opinion yet?  I've demonstrated that of all the major languages with which PHP compares (apologies to any languages I've forgotten) that PHP is the ONLY one that works like this and has no option to do it the other way.