Today is 29 January 2009. Ask someone today what next month is.

Their answer is “February”.

Ask PHP: print date('m/d/Y', strtotime('next month')); (In english: PHP, please give me a date that looks like MM/DD/YYYY for next month.)

03/01/2009 (1 March 2009)

As it turns out, like all things with computers, you’re asking it wrong. You should write print date('m/d/Y', strtotime(date('Y-m') . '-01 next month')) which is a convoluted way of saying “Give me a date, MM/DD/YYYY, for next month calculated from the first of this month.”

Okay, but this is a bug, right? I mean, php has a strtotime() function for the purpose of letting people write english statements and parsing them into real time values, and it’s acting incorrectly.

Wrong-o.

According to the PHP devs on numerous occasions this is purely correct behavior, and they even cite the GNU date format documentation as proof:

• PHP says “add one to the month on the date you gave us”
• You get 31 Feb 2009
• PHP says “that doesn’t exist!” and rolls it up to the next available real date, 1 March 2009

Except this is bullshit.

By their own admission (in the second linked bug above), the PHP developers get a bunch of bug reports because this doesn’t work as expected. Waving your hands and pointing at the GNU guys doesn’t make it okay, that’s passing the buck. Pointing back at the PHP manual in your standard form reply to these doesn’t help either: the manual page for strtotime() mentions nothing of how it might not work the way you expect it to.

Lesson to be taken away: if your users think it’s a bug, take a good look at it. It might be a bug.