ID: 45713 User updated by: kris dot craig at gmail dot com Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment:
You assume I don't already know that?? I told you, I've already researched this thoroughly. Yes, I am aware that this is the CAUSE of the bug, but it doesn't mean that it isn't still a bug nonetheless, it simply means that it'll be very difficult to solve. It is not bogus, and it was not appropriate to classify it as such. Instead, we should be talking about finding creative ways to solve the problem, other than just telling people to go out and get a 64-bit system. Perhaps try a different data type? Or return it as a string value if it goes beyond that size? These are just random ideas off the top of my head, of course, but my point is that there should be at least some deliberative effort put in to fixing this (or at least *discussing* ways to fix it) before simply dismissing it as "bogus" and insulting anyone who researches the issue and posts it as a bug report. Previous Comments: ------------------------------------------------------------------------ [2008-08-05 20:24:22] [EMAIL PROTECTED] Read it again, perhaps you then notice this one: "Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)" Of course, on a 64-bit platform this is not an issue. ------------------------------------------------------------------------ [2008-08-05 19:59:39] kris dot craig at gmail dot com It should be noted that this bug has been reported numerous times over the last few years (though not recently), and this is the first time anyone ever responded by trying to claim that it's somehow bogus. ------------------------------------------------------------------------ [2008-08-05 19:49:18] kris dot craig at gmail dot com Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. ------------------------------------------------------------------------ [2008-08-05 06:48:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read *all* the documentation at: http://no.php.net/strtotime Alternatively, use the OO date/time functionality: http://no.php.net/manual/en/function.date-create.php ------------------------------------------------------------------------ [2008-08-05 02:43:54] kris dot craig at gmail dot com Description: ------------ Any time I enter a date (any format) into strtotime that contains a year later than 2037, the function returns FALSE every time. If I change the year to 2037 or earler, without changing anything else, it works every time. I have not been able to find any documentation or other information to explain this phenomenon. Pertinent server/module/etc information can be found here: http://www.kriscraig.com/phpinfo.php Reproduce code: --------------- /* This could not be simpler.... */ print strtotime( "2012-05-06" ); //1336287600 (works) print strtotime( "12 May 2037" ); //2125724400 (works) print strtotime( "12 May 2038" ); // (doesn't work!) print strtotime( "2500-05-06" ); // (doesn't work!) Expected result: ---------------- They should all return a valid timestamp. FALSE should only be returned if it fails, which is not supposed to happen simply because the year being input is greater than 2037! Actual result: -------------- It returns FALSE. Nothing. Nada. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
