Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39250
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain smartertravelmedia.com designates 65.112.23.140 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Jul 2008 15:49:10 -0400
Message-ID: <7AFF263C3DBE2549899F71BB925794FF0492A863@sullivan.smartertravelmedia.com>
Thread-Topic: question about backward-compatibility break/bug in php 5.2.6
Thread-Index: Acjs/E0keTiVXBgTTrajzN0/cIMKJw==
To: <internals@lists.php.net>
Subject: question about backward-compatibility break/bug in php 5.2.6
From: jack@smartertravelmedia.com ("Jack Steadman")

Hello all,

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, rather
than returning false as it is supposed to.  Can someone explain to me
why this is "intended" behavior?  We do rely on strtotime returning
false on invalid dates, and this behavior changed between 5.2.5 and
5.2.6.  Do we need to update our code to check for this arbitrary
negative integer?  I would prefer not to do that.

Thanks,
Jack Steadman
Smarter Travel Media LLC

--------------------------------------------------
Operating system: RHEL 4/5
PHP version:      5.2.6
PHP Bug Type:     Date/time related
Bug description:  strtotime parses 0000-00-00 00:00:00 as valid date

Description:
------------
MySQL uses '0000-00-00 00:00:00' as a default value for non-null
datetime
fields.  Until 5.2.6, strtotime correctly returned false (or -1 before
5.1)
when passed this value - it's not a valid date/time.

5.2.6 returns '-62169966000' which is not useful.


Reproduce code:
---------------
<?php echo (int)strtotime('0000-00-00 00:00:00');


Expected result:
----------------
Should print 0.


Actual result:
--------------
Actually prints -62169966000.


[18 Jul 7:25am UTC] derick@php.net

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.=20

Thank you for your interest in PHP.

http://bugs.php.net/bug.php?id=3D42971
http://bugs.php.net/bug.php?id=3D44453

This is not a bug. MySQL is being silly to use this string as a default
value. In PHP 5.3 you can now detect this however, by using
date_parse_from_format( "Y-m-d H:i:s"); and then check the contents of
date_get_last_errors().

[18 Jul 1:31pm UTC] jack+phpdotnet at smartertravelmedia dot com

First of all, those previously-reported bugs are with the DateTime
class, not strtotime.  If DateTime uses strtotime or its underlying
implementation, that's not for me to know.  I searched the bug database
before submitting this report and did not find the two you mentioned.=20
Your "similar bugs" prompt didn't flag them either.

Second, how is this not a bug?  strtotime's manual page says, "Returns a
timestamp on success, FALSE otherwise."  The string of zeroes that mysql
uses is NOT a valid datetime string, so how is strtotime "successfully"
parsing it into a random negative number?  That's aside from the fact
that this is a behavior *change* from 5.2.5 to 5.2.6 - that alone makes
it a problem.

Third, you can think mysql is silly for using this as a default all you
want, but they've been doing it since at least version 3.23 if not
before.  Just because you don't agree with it doesn't mean PHP shouldn't
handle it as advertised - namely to return false if an invalid date/time
string is passed to strtotime.