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

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.

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.

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.

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.

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

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.

Derick has given you a solution, use the new DateTime class.

$date = new DateTime("12 May 2038"); echo $date->format("U");

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.