Till the date, the Y2K38 bug is not so widely known by the PHP developers. The year 2038 problem, usually named as "the Unix Millennium Bug" with the acronym Y2K38 (Y stands for Year, 2K for 2000 and 38 for the year) that cause some software to fail before or in the year 2038. The problem affects all software and systems (including PHP) that store system time as a signed 32-bit integer (timestamp), and interpret this number as the number of seconds since 00:00:00 UTC on January 1, 1970.
The basic problem is about the computer's capacity to count the time in seconds past to a certain date (01-01-2038). As Unix based systems measure the time in seconds from 1 January 1970, 03:14:07 UTC on 19 January 2038 is equal to 2,147,483,647 seconds after 1 January 1970. If stored on your system as a 32-bit date and time systems can only count up to 2,147,483,647 separate positive values, which means that the the system cannot continue counting the seconds past that time (kaboom for your application).
How to identify if my PHP version is susceptible to the bug?
To identify wheter the version of PHP that you use has the bug, you can run the following script:
<?php
// Define a date beyond 2038
$dateString = '2039-01-01';
$format = 'l d F Y H:i';
// Parse a textual date/datetime into a Unix timestamp
$date = strtotime($dateString);
// Print it
echo '<span>'. date($format, $date) .'</span>';
?>
If the printed text is "Wednesday 1 February 2040 00:00" then your PHP was surely compiled using the x64 version, otherwise "Thursday 01 January 1970 01:00" indicates that your PHP version has the bug.
Do I need to worry about this?
Till the date of this article, we have to wait 20 years to see how this bug starts to show up in applications. However, in that year your application would probably shouldn't be used anymore as it should be considered as "legacy", but we can't discard that it may still be used. So you may be worried, if your application is planned to be used for such a long time, however try to not be paranoic about it, at least, not yet.
As you may known (or probably not), there are been many issues in the past like the Y2K issue. So, it's someway besser to prevent than cure, isn't ? And there's a couple of ways to prevent this issue from happening on your project.
Possible solutions for PHP
You will sleep good at night without worriyng about the failure of your application in the year 2038 if:
1. You use a 64-bit OS with a compiled 64-bit edition of PHP
As mentioned initially, operative systems that support the x64 architecture and use a 64-bit compiled version of PHP won't have this issue. During and after 2038, this number will exceed 231 the largest number representable by a signed long integer on 32 bit systems, causing the Year 2038 problem. As a long integer in 64 bit systems uses 64 bits, the problem does not exist on 64 bit systems that use the LP64 model.
You can test the same snippet that we mentioned to identify the problem at the beginning of the article on some web service like writephponline and you will see the correct date, as they use a x64 based PHP version.
2. You use the DateTime instead of functions that use Unix timestamp
If your PHP code uses the strtotime function to manipulate time, try to avoid it. PHP introduced the DateTime class in the version 5.2 (entire availability with 5.3) that fixed the bug caused by the unix millenium issue. In this way, you won't need to run a x64 bit system with a compiled 64-bit edition of PHP. For example, try to run the initial snippet but using the DateTime class instead:
<?php
// Define a date beyond 2038
$dateString = '2039-01-01';
$format = 'l d F Y H:i';
// Parse a textual date/datetime into a Unix timestamp
$date = new DateTime($dateString);
// Print it
echo '<span>'. $date->format($format) .'</span>';
?>
Even if you are using a x86 (32-bits) PHP version (with at least PHP 5.2), the date will display Wednesday 1 February 2040 00:00 as expected. DateTime does not suffer from Y2K38 problems and will easily handle dates up to December 31, 9999. Probably (and hopefully) your system won't be used in that year.
Note that the same goes for other tools like MySQL (your database should store datetime or date instead of timestamps).
Interested on a detailed explanation of the bug?
This issue has a deep background that we ain't covering in this simple informative article. That's why, in case you are interested about the origin of the bug, detailed description, we recommend you to visit the 2038.org website by William Porquet, the main article provides interesting information about the issue.
If you have found this article useful and informative, please share it with your PHP developers friends, so they're aware of this bug as well.
