ID: 37281 Updated by: [EMAIL PROTECTED] -Summary: documentation contains a bogus claim Reported By: kprice at gmail dot com -Status: Open +Status: Closed Bug Type: Documentation problem PHP Version: Irrelevant New Comment:
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. "However, before PHP 5.1.0 this range was limited from 1970 to 2038 on some systems (e.g. Windows)." Previous Comments: ------------------------------------------------------------------------ [2007-03-07 18:55:58] morales2k at gmail dot com There is an article on Wikipedia about this thing... check here: http://en.wikipedia.org/wiki/Year_2038_problem ------------------------------------------------------------------------ [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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ 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
