Doc #53662 [Com]: strtotime() returns inconsistent output on 64 bit systems

Edit report at https://bugs.php.net/bug.php?id=53662&edit=1 ID: 53662 Comment by: steg2005 at gmail dot com Reported by: smenjas at gmail dot com Summary: strtotime() returns inconsistent output on 64 bit systems Status: Closed Type: Documentation Problem Package: Date/time related Operating System: Ubuntu 10.10 PHP Version: 5.3.4 Assigned To: frozenfire Block user comment: N Private report: N New Comment: Logic of strtotime SHOULD BE: Strtotime -> IF Running on 64-Bit AND input is 0000-00-00 00:00:00 then return NULL. Its fine if the date is in the past, just NOT when its 0000-00-00 00:00:00 (the default for date column value in MANY databases). This creates inconsistency in the PHP language across platforms is what im trying to say. It may not be a BUG but it makes PHP less of a reliable language due to the unexpected behaviour, and I'd like to see you SERIOUSLY consider fixing this. Previous Comments: ------------------------------------------------------------------------ [2011-10-26 00:24:16] rich at clearchaos dot com Another vote for adding "0000-00-00 00:00:00" as a special case that returns a timestamp of false (or make all zero days/months return false). The problem is that value is often used in MySQL datetime fields as a "null". Code written for 32-bit PHP often checks whether this equates to a zero timestamp to see whether the value is set. This may not be best practice, but it happens in the real world (just had to debug code with this problem myself). ------------------------------------------------------------------------ [2011-07-02 20:41:42] frozenfire@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. ------------------------------------------------------------------------ [2011-01-24 18:25:10] vita10gy at charter dot net Damn. Well then I second adding some sort of strict date option to the server config options where 2010-08-36 and 0000-00-00 are NOT valid, since documented or not, we could debate if that's a bug or a feature. :) ------------------------------------------------------------------------ [2011-01-24 18:10:38] vita10gy at charter dot net If you pass the returned timestamp back to date() you get -0001-11-30 00:00:00 0 might be a valid year, 0 isn't a valid month or day. Database dates can be nothing or 0000-00-00 00:00:00 if null isn't allowed, so the easiest check for both is to see if strtotime === false, or not. Obviously there are workarounds, but depending on the feasibility of changing lots of legacy code, this could be a show stopper for upgrading. 0000-00-00 00:00:00 is a nonsensical date and the timestamp returned is nonsense. Please return false. Pretty please? :) ------------------------------------------------------------------------ [2011-01-24 18:07:51] tjw at tjw dot org Nevermind, I see this underflow/overflow behavior is documented here http://us2.php.net/manual/en/datetime.formats.date.php. It might be nice if there were a "strict" option to turn this behavior off, but that's another story. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53662 -- Edit this bug report at https://bugs.php.net/bug.php?id=53662&edit=1