How do you explain the result for a new \DateTime('0000-00-00 00:00:00')?

Solution 1:

You are seeing two effects here. The first one is that you use a way of writing for a date that can be written in multiple forms:

0000-01-01 same as  0000-01-01
0000-01-00 same as -0001-12-31
0000-00-01 same as -0001-12-01
0000-00-00 same as -0001-11-30

So by the date itself, you already specify the 30th November -1.

Now there's the time offset left that differs about the 9 minutes and 21 seconds. That is because of a change in the clock compared to UTC in Paris/France that happened 10 Mar 1911 23:51:38/39 local time.

I modified your code example a bit and introduced the Europe/Paris setting as you have it, which is playing a role. This code is telling as well the offset in seconds from UTC (Z) which is what you're looking for:

$dt = new DateTime('0000-00-00 00:00:00', new DateTimeZone('Europe/Paris'));
printf("%s secs offset from UTC\n", $dt->format('r T (e) Z'));

I changed the dates a bit

Fri, 10 Mar 1911 23:51:38 +0009 PMT (Europe/Paris) 561 secs offset from UTC
                                                   ^^^

One second later:

Fri, 10 Mar 1911 23:51:39 +0000 WET (Europe/Paris) 0 secs offset from UTC

When local standard time was about to reach Saturday, 11 March 1911, 00:01:00 clocks were turned backward 0:09:21 hours to Friday, 10 March 1911, 23:51:39 local standard time instead.

That are 561 Secs. Reference: Clock changes in Paris - Time change dates in 1911 and Time zone changes and daylight saving time start/end dates between year 1900 and 1924.

Solution 2:

Looks like the error handling in DateTime is incomplete. Normally, other PHP functions handle '0000-00-00' as an error (invalid date).

DateTime should follow the same guidelines, but it doesn't. This code does not throw an Exception, even if it should:

try { $dt = new \DateTime('0000-00-00 00:00:00'); } 
catch (Exception $e) { var_dump($e); }
var_dump($dt); 
/* result:
object(DateTime)#1 (3) {
  ["date"]=>
  string(20) "-0001-11-30 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Berlin"
*/

Other functions do treat that input as an error:

var_dump(strtotime('0000-00-00 00:00:00'));  // returns: bool(false)

Seems like PHP has always had problems handling that case.. examples: Bug #30190, Bug #60288

Cite from the comments in PHP bug tracker:

0000-00-00 is a non-existant date (the day before 01-01-0001 was 31/12/-0001)