Req #60288 [Opn]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60288&edit=1 ID: 60288 User updated by: it at ezy2c dot com 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: Physically -00-00 00:00:00 is NOT a real date, however all major databases commonly use this as a default datetime value to differentiate between a valid and and an invalid date. Previous Comments: [2012-02-20 21:01:06] john at gbd dot co dot uk as -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 [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 -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
[PHP-BUG] Bug #60257 [NEW]: ZERO DATES IN STRTOTIME
From:
Operating system: CENTOS 5 64 bit
PHP version: 5.3.8
Package: Date/time related
Bug Type: Bug
Bug description:ZERO DATES IN STRTOTIME
Description:
Hi I have noticed that when i use zero date in windows it converts to the
expected 1970 date however on our Centos 5 Server it fails.
See live script http://amo2.flsecure.com/testdate.php
Test script:
---
EXAMPLE CODE:
$zerodate="-00-00 00:00:00";
$convertdate=date("Y-m-d H:i:s",strtotime(-00-00 00:00:00));
echo("ORIG: ".$zerodate." | CONVERTED: ".$convertdate.");
RESULT:
ORIG: -00-00 00:00:00 | CONVERTED: -0001-11-30 00:00:00
On MY WINDOWS BOX:
ORIG: -00-00 00:00:00 | CONVERTED: 1970-01-01 10:00:00
--
Edit bug report at https://bugs.php.net/bug.php?id=60257&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60257&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60257&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60257&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60257&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60257&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60257&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60257&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60257&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60257&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60257&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60257&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60257&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60257&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60257&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60257&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60257&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60257&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60257&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60257&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60257&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60257&r=mysqlcfg
Bug #60257 [Com]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60257&edit=1
ID: 60257
Comment by: it at ezy2c dot com
Reported by: it at ezy2c dot com
Summary:ZERO DATES IN STRTOTIME
Status: Open
Type: Bug
Package:Date/time related
Operating System: CENTOS 5 64 bit
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
After a search of the web I have uncovered that other users experience this in
lots of 5+ versions of PHP on 64-bit *unix OS's.
If its a 64 bit OS, strtotime should detect if its a ZERO date value (as mysql
uses as default value etc) ie. -00-00 00:00:00 and return the 1970 value as
my Windows machine does.
By the way my Windows Machine is a 64-Bit Windows 7 machine with XAMPP, and it
returns a 1970 date. Please Fix this as we have a LOT of code that relies on
strtotime's ability.
Previous Comments:
[2011-11-10 23:40:19] it at ezy2c dot com
Description:
Hi I have noticed that when i use zero date in windows it converts to the
expected 1970 date however on our Centos 5 Server it fails.
See live script http://amo2.flsecure.com/testdate.php
Test script:
---
EXAMPLE CODE:
$zerodate="-00-00 00:00:00";
$convertdate=date("Y-m-d H:i:s",strtotime(-00-00 00:00:00));
echo("ORIG: ".$zerodate." | CONVERTED: ".$convertdate.");
RESULT:
ORIG: -00-00 00:00:00 | CONVERTED: -0001-11-30 00:00:00
On MY WINDOWS BOX:
ORIG: -00-00 00:00:00 | CONVERTED: 1970-01-01 10:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=60257&edit=1
Bug #60257 [Com]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60257&edit=1
ID: 60257
Comment by: it at ezy2c dot com
Reported by: it at ezy2c dot com
Summary:ZERO DATES IN STRTOTIME
Status: Open
Type: Bug
Package:Date/time related
Operating System: CENTOS 5 64 bit
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
When I strtotime("-00-00 00:00:00") in the Linux Box I get -6217002,
when I do it on the windows box it returns NULL. Maybe this is the root of the
issue, at least when it returns NULL it converts to 1970-01-01 10:00:00
Previous Comments:
[2011-11-11 03:08:56] it at ezy2c dot com
After a search of the web I have uncovered that other users experience this in
lots of 5+ versions of PHP on 64-bit *unix OS's.
If its a 64 bit OS, strtotime should detect if its a ZERO date value (as mysql
uses as default value etc) ie. -00-00 00:00:00 and return the 1970 value as
my Windows machine does.
By the way my Windows Machine is a 64-Bit Windows 7 machine with XAMPP, and it
returns a 1970 date. Please Fix this as we have a LOT of code that relies on
strtotime's ability.
----
[2011-11-10 23:40:19] it at ezy2c dot com
Description:
Hi I have noticed that when i use zero date in windows it converts to the
expected 1970 date however on our Centos 5 Server it fails.
See live script http://amo2.flsecure.com/testdate.php
Test script:
---
EXAMPLE CODE:
$zerodate="-00-00 00:00:00";
$convertdate=date("Y-m-d H:i:s",strtotime(-00-00 00:00:00));
echo("ORIG: ".$zerodate." | CONVERTED: ".$convertdate.");
RESULT:
ORIG: -00-00 00:00:00 | CONVERTED: -0001-11-30 00:00:00
On MY WINDOWS BOX:
ORIG: -00-00 00:00:00 | CONVERTED: 1970-01-01 10:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=60257&edit=1
Bug #60257 [Com]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60257&edit=1
ID: 60257
Comment by: it at ezy2c dot com
Reported by: it at ezy2c dot com
Summary:ZERO DATES IN STRTOTIME
Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: CENTOS 5 64 bit
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Perhaps there should be an option to return NULL. This isnt great when your
dealing with MySQL databases that have date fields with -00-00 00:00:00
format. At least when it returns null the date field interprets it as the 1970
date. This is an expedted date wince 1970 is the start of unix epoch.
This Created variability over 32-bit and 64-bit systems and hence would need to
adjust the code base to do something kind of work around (however some systems
use lots of date values and this is VERY difficult to replace all the strtotime
references) see below for a wrapper function. I feel that this logic SHOULD
exist in 64 bit ONLY if the date is -00-00 00:00:00, this way database
default values can be handles easier and is cross compatible in both 64 or 32
bit systems.
YOUR view maybe that is isnt a BUG, however its more of Incompatibility and
Inconsistency across platforms and 32/64 bit systems. I would VERY much like
you to consider changing this.
function str2time($time)
{
if(strtotime($time)=="-6217002")
{
return NULL;
}
else
{
return strtotime($time);
}
}
Previous Comments:
[2011-11-11 12:25:09] ahar...@php.net
Not a bug: on 64 bit platforms, -00-00 00:00:00 is within range, so
strtotime() returns a UNIX timestamp corresponding to that date. On 32 bit
platforms, it's out of range, so strtotime() returns NULL to signal the error.
Duplicate of bug #53662 (among others).
[2011-11-11 03:31:33] it at ezy2c dot com
When I strtotime("-00-00 00:00:00") in the Linux Box I get -6217002,
when I do it on the windows box it returns NULL. Maybe this is the root of the
issue, at least when it returns NULL it converts to 1970-01-01 10:00:00
--------
[2011-11-11 03:08:56] it at ezy2c dot com
After a search of the web I have uncovered that other users experience this in
lots of 5+ versions of PHP on 64-bit *unix OS's.
If its a 64 bit OS, strtotime should detect if its a ZERO date value (as mysql
uses as default value etc) ie. -00-00 00:00:00 and return the 1970 value as
my Windows machine does.
By the way my Windows Machine is a 64-Bit Windows 7 machine with XAMPP, and it
returns a 1970 date. Please Fix this as we have a LOT of code that relies on
strtotime's ability.
------------
[2011-11-10 23:40:19] it at ezy2c dot com
Description:
Hi I have noticed that when i use zero date in windows it converts to the
expected 1970 date however on our Centos 5 Server it fails.
See live script http://amo2.flsecure.com/testdate.php
Test script:
---
EXAMPLE CODE:
$zerodate="-00-00 00:00:00";
$convertdate=date("Y-m-d H:i:s",strtotime(-00-00 00:00:00));
echo("ORIG: ".$zerodate." | CONVERTED: ".$convertdate.");
RESULT:
ORIG: -00-00 00:00:00 | CONVERTED: -0001-11-30 00:00:00
On MY WINDOWS BOX:
ORIG: -00-00 00:00:00 | CONVERTED: 1970-01-01 10:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=60257&edit=1
Bug #60257 [Com]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60257&edit=1
ID: 60257
Comment by: it at ezy2c dot com
Reported by: it at ezy2c dot com
Summary:ZERO DATES IN STRTOTIME
Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: CENTOS 5 64 bit
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Wow, OK. The Spell check went horrible. :)
However the logic of strtotime SHOULD BE:
Strtotime -> IF Running on 64-Bit AND input is -00-00 00:00:00 then return
NULL.
Its fine if the date is in the past, just NOT when its -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-11-13 21:44:42] it at ezy2c dot com
Perhaps there should be an option to return NULL. This isnt great when your
dealing with MySQL databases that have date fields with -00-00 00:00:00
format. At least when it returns null the date field interprets it as the 1970
date. This is an expedted date wince 1970 is the start of unix epoch.
This Created variability over 32-bit and 64-bit systems and hence would need to
adjust the code base to do something kind of work around (however some systems
use lots of date values and this is VERY difficult to replace all the strtotime
references) see below for a wrapper function. I feel that this logic SHOULD
exist in 64 bit ONLY if the date is -00-00 00:00:00, this way database
default values can be handles easier and is cross compatible in both 64 or 32
bit systems.
YOUR view maybe that is isnt a BUG, however its more of Incompatibility and
Inconsistency across platforms and 32/64 bit systems. I would VERY much like
you to consider changing this.
function str2time($time)
{
if(strtotime($time)=="-6217002")
{
return NULL;
}
else
{
return strtotime($time);
}
}
[2011-11-11 12:25:09] ahar...@php.net
Not a bug: on 64 bit platforms, -00-00 00:00:00 is within range, so
strtotime() returns a UNIX timestamp corresponding to that date. On 32 bit
platforms, it's out of range, so strtotime() returns NULL to signal the error.
Duplicate of bug #53662 (among others).
----
[2011-11-11 03:31:33] it at ezy2c dot com
When I strtotime("-00-00 00:00:00") in the Linux Box I get -6217002,
when I do it on the windows box it returns NULL. Maybe this is the root of the
issue, at least when it returns NULL it converts to 1970-01-01 10:00:00
------------
[2011-11-11 03:08:56] it at ezy2c dot com
After a search of the web I have uncovered that other users experience this in
lots of 5+ versions of PHP on 64-bit *unix OS's.
If its a 64 bit OS, strtotime should detect if its a ZERO date value (as mysql
uses as default value etc) ie. -00-00 00:00:00 and return the 1970 value as
my Windows machine does.
By the way my Windows Machine is a 64-Bit Windows 7 machine with XAMPP, and it
returns a 1970 date. Please Fix this as we have a LOT of code that relies on
strtotime's ability.
----------------
[2011-11-10 23:40:19] it at ezy2c dot com
Description:
Hi I have noticed that when i use zero date in windows it converts to the
expected 1970 date however on our Centos 5 Server it fails.
See live script http://amo2.flsecure.com/testdate.php
Test script:
---
EXAMPLE CODE:
$zerodate="-00-00 00:00:00";
$convertdate=date("Y-m-d H:i:s",strtotime(-00-00 00:00:00));
echo("ORIG: ".$zerodate." | CONVERTED: ".$convertdate.");
RESULT:
ORIG: -00-00 00:00:00 | CONVERTED: -0001-11-30 00:00:00
On MY WINDOWS BOX:
ORIG: -00-00 00:00:00 | CONVERTED: 1970-01-01 10:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=60257&edit=1
Bug #60257 [Com]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60257&edit=1
ID: 60257
Comment by: it at ezy2c dot com
Reported by: it at ezy2c dot com
Summary:ZERO DATES IN STRTOTIME
Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: CENTOS 5 64 bit
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This bug is obviously a duplicate because many people feel its a mistake and
affects their database driven enterprise sites.
I would very much appreciate it if I could request for an extra parameter to be
added ie. strtotime ( string $time [, int $now = time() ], [legacy32bit =
boolean] )
So when its used on a 64-bit system (if you dont want to return an ambiguous
date) you can specify to return the unix epoch as it did in 32-bit.
A lot of small companies start at 32-bit and their code uses strtotime and due
to this problem it CANNOT be easily ported/upgraded to 64-bit as their company
expands.
While its great to see that you support a large range of dates (292 billion
years into the past and 292 billion years into the future) its not always
wanted or necessary or useful when you are dealing with common dates your
converting for enterprise purposes.
Previous Comments:
[2011-11-13 21:51:51] it at ezy2c dot com
Wow, OK. The Spell check went horrible. :)
However the logic of strtotime SHOULD BE:
Strtotime -> IF Running on 64-Bit AND input is -00-00 00:00:00 then return
NULL.
Its fine if the date is in the past, just NOT when its -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.
[2011-11-13 21:44:42] it at ezy2c dot com
Perhaps there should be an option to return NULL. This isnt great when your
dealing with MySQL databases that have date fields with -00-00 00:00:00
format. At least when it returns null the date field interprets it as the 1970
date. This is an expedted date wince 1970 is the start of unix epoch.
This Created variability over 32-bit and 64-bit systems and hence would need to
adjust the code base to do something kind of work around (however some systems
use lots of date values and this is VERY difficult to replace all the strtotime
references) see below for a wrapper function. I feel that this logic SHOULD
exist in 64 bit ONLY if the date is -00-00 00:00:00, this way database
default values can be handles easier and is cross compatible in both 64 or 32
bit systems.
YOUR view maybe that is isnt a BUG, however its more of Incompatibility and
Inconsistency across platforms and 32/64 bit systems. I would VERY much like
you to consider changing this.
function str2time($time)
{
if(strtotime($time)=="-6217002")
{
return NULL;
}
else
{
return strtotime($time);
}
}
[2011-11-11 12:25:09] ahar...@php.net
Not a bug: on 64 bit platforms, -00-00 00:00:00 is within range, so
strtotime() returns a UNIX timestamp corresponding to that date. On 32 bit
platforms, it's out of range, so strtotime() returns NULL to signal the error.
Duplicate of bug #53662 (among others).
----
[2011-11-11 03:31:33] it at ezy2c dot com
When I strtotime("-00-00 00:00:00") in the Linux Box I get -6217002,
when I do it on the windows box it returns NULL. Maybe this is the root of the
issue, at least when it returns NULL it converts to 1970-01-01 10:00:00
------------
[2011-11-11 03:08:56] it at ezy2c dot com
After a search of the web I have uncovered that other users experience this in
lots of 5+ versions of PHP on 64-bit *unix OS's.
If its a 64 bit OS, strtotime should detect if its a ZERO date value (as mysql
uses as default value etc) ie. -00-00 00:00:00 and return the 1970 value as
my Windows machine does.
By the way my Windows Machine is a 64-Bit Windows 7 machine with XAMPP, and it
returns a 1970 date. Please Fix this as we have a LOT of code that relies on
strtotime's ability.
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=60257
--
Edit this bug report at https://bugs.php.net/bug.php?id=60257&edit=1
[PHP-BUG] Req #60288 [NEW]: ZERO DATES IN STRTOTIME
From: Operating system: CENTOS 5 64 bit PHP version: 5.3.8 Package: Date/time related Bug Type: Feature/Change Request Bug description:ZERO DATES IN STRTOTIME 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 -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 bug report at https://bugs.php.net/bug.php?id=60288&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60288&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60288&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60288&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60288&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60288&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60288&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60288&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60288&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60288&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60288&r=support Expected behavior: https://bugs.php.net/fix.php?id=60288&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60288&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60288&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60288&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60288&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60288&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60288&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60288&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60288&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60288&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60288&r=mysqlcfg
Req #60288 [Com]: ZERO DATES IN STRTOTIME
Edit report at https://bugs.php.net/bug.php?id=60288&edit=1 ID: 60288 Comment by: it at ezy2c dot com 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: 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. Previous Comments: [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 -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
