As usual I started with the most recently filed bugs and ran into bug #63776, which turned out to not be a bug. Titled "strtotime fails with 'at'" it goes about how a date string with at in it (like in "Nov 19, 2012 at 7:03 PM") does not get parsed properly with strtotime() (or really any other parsing routing). strtotime()'s documentation page mentions The function expects to be given a string containing an English date format and will try to parse that format into a Unix timestamp. The word "try" is quite important here. In general, people are a lot better at this sort of thing than computers, as they sense what is part of the data and what is noise. In this case, the parser routine sees the phrase at as a timezone abbreviation, which it does not understand. And because of this, it refuses to parse the string. If you use date_parse() you will see what it actually parsers out of the string:

var_dump( date_parse( "Nov 19, 2012 at 7:03 PM" ) );

which outputs (reformatted):

array(13) {
  'year' => int(2012)
  'month' => int(11)
  'day' => int(19)
  'hour' => int(19)
  'minute' => int(3)
  'second' => int(0)
  'fraction' => double(0)
  'warning_count' => int(0)
  'warnings' => array(0) { }
  'error_count' => int(1)
  'errors' => array(1) {
    [13] => string(47) "The timezone could not be found in the database"
  }
  'is_localtime' => bool(true)
  'zone_type' => int(0)
}

Which mentions very clearly [13] => string(47) "The timezone could not be found in the database" — the key 13 is the position in the original string.

The next one, bug #64294, with the title "date conversion problem when dst present" turned out not to be a bug either. Simply forgotten that Daylight Saving Time already had gone away for the year. However, I should point out that parsing a timestamp with: $date = new \DateTime('@ 1382954400'); always sets the timezone UTC, and not the configured default. This means that:

<?php
$timestamp = 1382954400;
$date = new \DateTime('@'.$timestamp);
echo $date->format('Y-m-d H:i O'), "\n";
?>

Will always show a timezone of +0000:

2013-10-28 10:00 +0000

However, there was a bug that needed a fix. Bug #53879, "DateTime::createFromFormat() fails to parse cookie expiration date" talks about parsing a date string such as Mon, 21-Jan-2041 15:24:52 GMT with the factory method DateTime::createFromFormat(). This method takes as first argument a series of format specifiers to signal how the date string should be parsed. It mostly uses the same format letters that the DateTime::format() method uses to output a DateTime object in a specific format.

In this case, the user did not specify his own format, but used one of the predefined constants that is meant for displaying a DateTime object in a format that HTTP Cookies want. The constant DateTime::COOKIE was in fact just the string l, d-M-y H:i:s T. The y here stands for a two-digit year. Specifying the year in two digits appeared in the original RFC 850 but has since then be superseded by a whole bunch of interconnecting and contradicting standards.

The general consensus seems to be what is now on http://curl.haxx.se/rfc/cookie_spec.html, but that was formerly hosted on a now-defunct netscape.com page. This pages defines the date format as needed for cookies as:

The date string is formatted as:

Wdy, DD-Mon-YYYY HH:MM:SS GMT

This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes.

In PHP, Wdy, DD-Mon-YYYY HH:MM:SS GMT is represented as l, d-M-Y H:i:s T to which I now changed PHP's DateTime::COOKIE constant.

There are plenty more issues, so we'll be coming back to the DateTime extension.