Thisbugiscausedbyusing4bytessignedintegerusedtomakequickaccounts.

Theproblem:

Thereisnouniversalsolutiontotheyear2038problem,anyChangingtime_tsettingcanresultincompatibilityissuesinanyapplication

Forexample,changingtime_ttoanunsigned32-bitinteger,whichwouldextendtherangetoyear2106,wouldadverselyaffectprogramsthatstore,retrieve,ormanipulatedatesbefore1970,sincesuchdatesarerepresentedbynegativenumbers.Increasingthesizeofthe%typeof64-bit%inanexistingsystemwouldcauseincompatiblechangestothelayoutoftheinterfacestructuresandthebinaryfunctions.

Wikipedia - Solutions

Just to complement the answer, I want to point out that with the DateTime class I did not have this problem.

See:

$date = new DateTime('+1000 years')

echo $date->format('c'); // 3015-11-25T09:20:54-02:00

Tested on the command line with psysh .

Update : In ideone.com , only the form highlighted in my example works. The form using the date function fails.

link

Note : All this will work perfectly with DateTime , unless you use DateTime::getTimestamp .

Testing

A good way to test these limitations can be done through PHP_INT_MAX , which can probably be changed in different versions of PHP.

Test 1 psysh , PHP 5.5.9 Ubuntu:

$date = new DateTime();
$date->setTimestamp(PHP_INT_MAX);
var_dump($date->format('c')); // 219250468-12-04T13:30:07-02:00
var_dump(PHP_INT_MAX); // int(9223372036854775807)

Test 2 ideone.com :

$date = new DateTime();
$date->setTimestamp(PHP_INT_MAX);
var_dump($date->format('c')); // 2038-01-19T03:14:07+00:00

var_dump(PHP_INT_MAX); // int(2147483647)

Notice that in both cases, different results were returned. So I can also assume that, because of the integer maximum size processed in PHP, this might affect the behavior of the functions.

Use the methods of class \DateTime . This way, the dates generated by your application are not limited by the architecture that PHP is running (in this case, 32 bits).