ID: 45713
Updated by: [EMAIL PROTECTED]
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:
Derick has given you a solution, use the new DateTime class.
$date = new DateTime("12 May 2038"); echo $date->format("U");
Previous Comments:
------------------------------------------------------------------------
[2008-08-05 21:21:06] kris dot craig at gmail dot com
Perhaps you shouldn't be responding to these bug postings? You seem to
respond only by hurling childish insults, this time belittling my
intelligence by alleging that I don't know how to read. I did read your
posts, including the suggestion about using date_create. But that is a
workaround, not a solution. A solution would be fixing strtotime() and
other similar functions so that they can accept a year past 2037-- some
have said it's like "Unix's Y2K"; i.e. we're going to have to address it
eventually, so why wait 'till the last minute?
At very least, we should update the documentation on that function to
clearly outline this limitation, including the reasons behind it, and a
suggested workaround. However, I think that should be the "Plan B"
resolution, in the event that we can't find something better. But we
won't if you keep reducing the level of this dialogue by including
childish, non-constructive, unprofessional insults in your responses.
------------------------------------------------------------------------
[2008-08-05 21:13:41] [EMAIL PROTECTED]
I already wrote about the alternative in my first comment, but because
reading is obviously hard for you, I'll paste you the URL again:
http://no.php.net/date_create
------------------------------------------------------------------------
[2008-08-05 20:54:20] kris dot craig at gmail dot com
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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/45713
--
Edit this bug report at http://bugs.php.net/?id=45713&edit=1
