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:
No, he hasn't. That isn't a solution. It's a workaround. I already
said that in my last post.
If this is the best we can do, then strtotime() should be depreciated,
and the PHP documentation should point all users to the new DateTime
class.
Either way, this isn't a solution as it stands now. At very least the
documentation for strtotime() needs some serious updating.
Previous Comments:
------------------------------------------------------------------------
[2008-08-05 22:08:22] [EMAIL PROTECTED]
Derick has given you a solution, use the new DateTime class.
$date = new DateTime("12 May 2038"); echo $date->format("U");
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
