Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39258
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender)
Message-ID: <48884251.1020300@gmx.net>
Date: Thu, 24 Jul 2008 10:50:25 +0200
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Jack Steadman <jack@smartertravelmedia.com>
CC: internals@lists.php.net
References: <7AFF263C3DBE2549899F71BB925794FF0492A863@sullivan.smartertravelmedia.com>
In-Reply-To: <7AFF263C3DBE2549899F71BB925794FF0492A863@sullivan.smartertravelmedia.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] question about backward-compatibility break/bug in
 php 5.2.6
From: chris_se@gmx.net (Christian Seiler)

Hi,

> Last week I submitted a bug report on the issue described below.  The
> response (also below) was that this is not a bug.  I fail to see how it
> could *not* be a bug given that strtotime is parsing an invalid date
> into a seemingly-arbitrary and definitely-meaningless number,

strtotime() has always accepted month and day numbers 0 in order to
express "last month of the previos year" and "last day of the previous
month". Take:

var_dump (date ('Y-m-d H:i:s', strtotime ('2008-00-01 12:00:00')));

This gives:

string(19) "2007-12-01 12:00:00"

Here, the 00 is interpreted as "month before January" and thus December
of the previous year. Then, take:

var_dump (date ('Y-m-d H:i:s', strtotime ('2008-02-00 12:00:00')));

This gives:

string(19) "2008-01-31 12:00:00"

Here, the 00 is interpreted as "day before the first day of that month"
and thus the 31st of January.

Take both together, you get:

var_dump (date ('Y-m-d H:i:s', strtotime ('2008-00-00 12:00:00')));
string(19) "2007-11-30 12:00:00"

Now, take the date '0000-01-01'. This is a valid date according to ISO
8601 and simply means the 1st of January in 1 BC (but according to a
proleptic gregorian calendar, because ISO 8601 defines it as that). So
'0000-00-00' is actually the 30th of November of 2 BC (proleptic
gregorian calendar).

Now, the return value of strtotime() is actually defined as the number
of seconds since the 1st of January 1970, 00:00:00 UTC. If you add
-62169966000 seconds to that date, you get the 30th of November 2 BC
(proleptic gregorian calendar) at 00:00:00 of your time zone.

Also, it is not a regression. On my 32bit CPU, strtotime() still returns
false for your date since a 32bit integer cannot represent such a large
number and thus strtotime() can't return a valid timestamp. But on a
64bit CPU, integers are large enough to hold that number and strtotime()
can return a valid timestamp. If you compile a very old PHP version on a
64bit system, it will yield the same results.

As somebody already commented in the bug reports: It's not a bug.

You can write yourself a wrapper if you want to catch that specific date:

function my_strtotime($str, $ts = null) {
   if ($ts === null) $ts = time ();
   return $str == '0000-00-00 00:00:00' ? false : strtotime ($str, $ts);
}

Regards,
Christian