This is expected.  On 64-bit systems the date range supported is much larger than 
on 32-bit systems.

Thanks for the incredibly prompt reply.

That makes sense, except that to the best of my knowledge the year zero is not valid in either the Julian or Gregorian calendars.

I had assumed that strtotime would return FALSE for invalid dates.  On my 32 bit Ubuntu system, this appears to the case.  strtotime("2011-01-32") returns FALSE, as opposed to returning the timestamp for "2011-02-01".

An in depth reading of the documentation did not clarify how strtotime() should be expected to handle invalid date strings.

PHP uses the version of the proleptic Gregorian calendar specified by
ISO 8601, which does include a year 0 (equivalent to 1 BC in the
traditional Gregorian calendar).

And you get false in 32-bit systems because year 0 falls outside the supported 
range that fits in a 32-bit signed integer.  The range for 32-bit covers about 136 
years starting at 1901-12-13 and ending at 2038-01-19

Thanks for taking the time to point that out, and thanks for PHP!

For a read on the used calendar: http://derickrethans.nl/unix-epoch-and-phps-calendar-system.html

Blog post are not documentation, if the docs do not have this info then let mark 
this bug as "to be documented".

Shouldn't "0000-00-00 00:00:00" return false because there is no 00 month or 00 day in any month?

Nevermind, I see this underflow/overflow behavior is documented here http://us2.php.net/manual/en/datetime.formats.date.php.  It might be nice if there were a "strict" option to turn this behavior off, but that's another story.

If you pass the returned timestamp back to date() you get -0001-11-30 00:00:00

0 might be a valid year, 0 isn't a valid month or day. 

Database dates can be nothing or 0000-00-00 00:00:00 if null isn't allowed, so the easiest check for both is to see if strtotime === false, or not. Obviously there are workarounds, but depending on the feasibility of changing lots of legacy code, this could be a show stopper for upgrading.

0000-00-00 00:00:00 is a nonsensical date and the timestamp returned is nonsense. Please return false.

Pretty please? :)

Damn.

Well then I second adding some sort of strict date option to the server config options where 2010-08-36 and 0000-00-00 are NOT valid, since documented or not, we could debate if that's a bug or a feature. :)

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Another vote for adding "0000-00-00 00:00:00" as a special case that returns a timestamp of false (or make all zero days/months return false).

The problem is that value is often used in MySQL datetime fields as a "null". Code written for 32-bit PHP often checks whether this equates to a zero timestamp to see whether the value is set. This may not be best practice, but it happens in the real world (just had to debug code with this problem myself).

Logic of strtotime SHOULD BE:

Strtotime -> IF Running on 64-Bit AND input is 0000-00-00 00:00:00 then return NULL.

Its fine if the date is in the past, just NOT when its 0000-00-00 00:00:00 (the default for date column value in MANY databases).

This creates inconsistency in the PHP language across platforms is what im trying to say. It may not be a BUG but it makes PHP less of a reliable language due to the unexpected behaviour, and I'd like to see you SERIOUSLY consider fixing this.