#37281 [Com]: documentation contains a bogus claim
| From: | morales2k at gmail dot com | Date: | Wed, 07 Mar 2007 18:55:58 +0000 |
| Subject: | #37281 [Com]: documentation contains a bogus claim | ||
| References: | 1 | Groups: | php.doc |
| Request: | Send a blank email to phpdoc+get-969375749@lists.php.net to get a copy of this message | ||
ID: 37281
Comment by: morales2k at gmail dot com
Reported By: kprice at gmail dot com
Status: Open
Bug Type: Documentation problem
PHP Version: Irrelevant
New Comment:
There is an article on Wikipedia about this thing... check here:
http://en.wikipedia.org/wiki/Year_2038_problem
Previous Comments:
------------------------------------------------------------------------
[2007-03-07 18:52:09] jmorales at tucms dot com
Using this you get the error in DATE():
echo date("M d, Y", strtotime("12/4/2038");
This day is outside the 32 bit range and it overflows the 32bit stack.
I am using PHP 4.4 i forgot the rest, but version should be
irrelevant... is anyone else getting this on v5.x.x ???
------------------------------------------------------------------------
[2006-11-11 13:05:03] derick@php.net
php -r '$a = new DateTime("1/1/1901"); echo $a->format("U");'
-2177456400
However, you do have a point. I think we even break to 32bit ints on 64
bit systems. I can check that when somebody grants me access to a 64bit
machine.
------------------------------------------------------------------------
[2006-11-11 03:11:45] lucas at facebook dot com
Derick, is this true even on 64bit systems? We've run into this problem
using mktime and strtotime on 5.2. For example:
mktime(0,0,0,1,1,1901) returns false
strtotime("1/1/1901") returns false
However
date('r', -2178099690) returns:
Mon, 24 Dec 1900 04:18:30 -0800
I have not figured out how to return the timestamp from a DateTime
object created with the string "1/1/1901".
------------------------------------------------------------------------
[2006-05-03 11:25:25] derick@php.net
It's a documentation problem. Although *internally* the new code does
support larger numbers it still can not return larger integers back to
user land. So for calling PHP functions the result can never be outside
this range.
However, the new date code which is going to make it into PHP 5.2 is
going to provide functions to deal with this correctly.
------------------------------------------------------------------------
[2006-05-02 19:11:37] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the
report.
Please also tell what your system is.
------------------------------------------------------------------------
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
http://bugs.php.net/37281
--
Edit this bug report at http://bugs.php.net/?id=37281&edit=1