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? 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. > 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. This is not actually the case. Take one of our machines (first part of php -i included here): System => Linux wollaston 2.6.9-55.0.9.ELsmp #1 SMP Tue Sep 25 02:16:15 EDT 2007 x86_64 Build Date => Jul 22 2008 11:41:54 Configure Command => './configure' '--with-mysql=/usr/lib64' '--with-gettext' '--with-openssl' '--enable-ftp' '--with-zlib-dir=/usr/lib64' '--enable-pcntl' '--with-pdo-mysql=/usr' '--without-sqlite' '--without-pdo-sqlite' '--with-apac he=../apache_1.3.41' '--with-curl' '--enable-cli' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => /usr/local/lib Loaded Configuration File => /usr/local/Zend/Platform/etc/php.ini PHP API => 20041225 PHP Extension => 20060613 Zend Extension => 220060519 Debug Build => no Thread Safety => disabled Zend Memory Manager => enabled IPv6 Support => enabled Registered PHP Streams => php, file, data, http, ftp, compress.zlib, https, ftps Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters => string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, zlib.* This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v3.2.8, Copyright (c) 1998-2007, by Zend Technologies with jobqueue_client wrapper v1.0, Copyright (c) 2004-2007, by Zend Technologies with DISABLED Zend Download Server v1.0.6, Copyright (c) 2003-2005, by Zend Technologies with DISABLED Zend Platform v3.0.3, Copyright (c) 1999-2007, by The Zend Platform presently supports only Apache, ISAPI and FastCGI SAPIs with Zend Debugger v5.2.8, Copyright (c) 1999-2007, by Zend Technologies with gd wrapper v1.0, Copyright (c) 2004-2007, by Zend Technologies with mod_cluster wrapper v1.0, Copyright (c) 2004-2007, by Zend Technologies 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. Downgrading back to 5.2.5 fixed the problem and it again returns false. Aside from that, the original tests I ran and included with the bug report were both run on 64-bit machines, one running 5.2.5 and the other (the machine whose info is above) running 5.2.6. In fact we don't have any 32-bit machines for me to even try this out on. *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. Jack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
