Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39254
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain users.sourceforge.net from 213.197.162.99 cause and error)
Message-ID: <52967.c316b4e9.1216877642.nsm@avilys.eik.lt>
In-Reply-To: 
     <7AFF263C3DBE2549899F71BB925794FF0492A863@sullivan.smartertravelmedia.
     com>
References:
    <7AFF263C3DBE2549899F71BB925794FF0492A863@sullivan.smartertravelmedia.com>
Date: Thu, 24 Jul 2008 08:34:02 +0300 (EEST)
To: internals@lists.php.net
User-Agent: NaSMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] question about backward-compatibility break/bug in 
     php 5.2.6
From: tokul@users.sourceforge.net ("Tomas Kuliavas")

> 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.

Date is not invalid. Some diety was born at -62169966000 Unixtime.

-- 
Tomas