RE: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
| From: | Derick Rethans | Date: | Fri, 25 Jul 2008 11:12:11 +0000 |
| Subject: | RE: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-39322@lists.php.net to get a copy of this message | ||
On Thu, 24 Jul 2008, Jack Steadman wrote:
> Thank you for taking the time to explain this to me. A couple more
> points below:
>
> > 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:
>
> So my biggest issue with this is that it's exception-case behavior,
> treating truly invalid dates as valid dates for no obvious reason. Who
> needs this functionality? Why is it even a good idea?
It's nice to find the last day of next month.
> A close second is that this behavior is completely undocumented.
> http://us.php.net/strtotime states that the time argument to
> strtotime
> is "The string to parse, according to the GNU > Date Input Formats
> syntax" and that false is returned on failure. GNU date formats do NOT
> allow for zero months and days (see
>
> http://www.gnu.org/software/tar/manual/html_node/Calendar-date-items.htm
> l#SEC116). No official mention is made of the exception case that you
> describe. The closest the docs come is a user comment on the strtotime
> page from June 19 of this year (perhaps someone who upgraded to 5.2.6
> and found this behavior for the first time?) warning other users that
> 2008-00-14 is interpreted as 2007-12-14.
Yes, the documentation is broken. I'm working on fixing that.
> This is not actually the case. Take one of our machines (first part of
> php -i included here):
<snip>
> This 64-bit machine is running 5.2.5 and returns false on the all-zero
> datetime string. It was upgraded last week to 5.2.6 and started
> returning the large negative integer.
<snip>
> *Something* changed in date handling between 5.2.5 and 5.2.6. Whether
> you perpetuate the exception case or not, it *is* a regression.
Yes, because there was a regression in 5.2.[45]:
php-5.2.6$ sapi/cli/php -n -r 'var_dump( strtotime( "0000-00-00 00:00" ) );'
int(-62169987600)
php-5.2.5$ sapi/cli/php -n -r 'var_dump( strtotime( "0000-00-00 00:00" ) );'
bool(false)
php-5.2.4$ sapi/cli/php -n -r 'var_dump( strtotime( "0000-00-00 00:00" ) );'
bool(false)
even in PHP 5.1 it doesn't return false (although it's incorrect):
$ php-5.1dev -n -r 'var_dump( strtotime( "0000-00-00 00:00" ) );'
int(943916400)
and *even* on 4.3.9:
$ php-4.3.9 -n -r 'var_dump( strtotime( "0000-00-00 00:00" ) );'
int(943916400)
regards,
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org