The Y2K38 Bug (also known as the Unix Millennium Bug), affects PHP and several other languages, such as Perl, Ruby or Python, and systems, such as those running on Unix and Macintosh computers, which use a signed 32-bit integer to represent dates as the number of seconds since 00:00:00 UTC on 1 January 1970. The furthest date which can be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is set and the integer becomes a negative decimal number, or a time prior to that date.
Although the count-down is still 28 years away and most programs will only be affected on 2038 or close to it, other software that work with future dates will begin developing glitches much earlier. For example, a program that works with dates 20 years in the future will have to be fixed no later than 2018.
There have been some problems of that kind already, such as the software running on a AOL server that was designed with a kludge to handle a database request that should “never” time out specified an arbitrary time-out date in the future. The default configuration for the server specified that the request should time out after one billion seconds. One billion seconds (approximately thirty-two years) after 9:27.28 pm on 12 May 2006 is beyond the 2038 cutoff date. Thus, after this time, the time-out calculation overflowed and returned a date that was actually in the past, causing the software to crash. When the problem was discovered, AOL’s server managers had to edit the configuration file and set the time out to a lower value
Probably, if you’re using a 64-bit OS with a compiled 64-bit edition of PHP, your application shouldn’t be affected. A signed 64-bit number gives a maximum future date which is 21 times greater than the current age of the universe, approximately 292 billion years from now, on Sunday, 4 December 292,277,026,596 CE.