Req #60288 [Com]: ZERO DATES IN STRTOTIME
| From: | john at gbd dot co dot uk | Date: | Mon, 20 Feb 2012 21:01:06 +0000 |
| Subject: | Req #60288 [Com]: ZERO DATES IN STRTOTIME | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-167664@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=60288&edit=1
ID: 60288
Comment by: john at gbd dot co dot uk
Reported by: it at ezy2c dot com
Summary: ZERO DATES IN STRTOTIME
Status: Open
Type: Feature/Change Request
Package: Date/time related
Operating System: CENTOS 5 64 bit
PHP Version: 5.3.8
Block user comment: N
Private report: N
New Comment:
as 0000-00-00 is a non-existant date (the day before 01-01-0001 was 31/12/-0001)
then strtotime() should return NULL on all systems
Previous Comments:
------------------------------------------------------------------------
[2011-11-14 03:17:58] it at ezy2c dot com
The Optional parameter could be set to DEFAULT of TRUE, that way it works as it would on 32-bit.
However if you want to use a date 292 billion years ij the past or future, specify FALSE.
------------------------------------------------------------------------
[2011-11-14 03:16:07] it at ezy2c dot com
Description:
------------
If you could please include a 3rd switch to strtotime ( string $time [, int $now = time() ],
[legacy32bit = boolean] )
This would both allow large date ranges as well is be backwards supporting of database default
timestamps ie 0000-00-00 00:00:00 they get converted to an ambiguous -0001-11-30 00:00:00.
if it was used like this strtotime($DBROW['timestampcolumn'], time(), true) and it returns
NULL as it did in the 32-bit version this whole issue could be avoided and it can still support a
very large date range.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=60288&edit=1