Will your PHP Applications be Affected by the Y2K38 Bug?
I don’t wish to alarm you too much but try running the following script on your web server.
<?php
//the date to test
$thedate = ’2040-02-01′;
//create a date string using the well known strtotime
$mydate = strtotime($thedate);
//lets print the result
echo ‘<p>’, date(‘l d F Y H:i’, $mydate), ‘</p>’;
?>
With any luck, you’ll see “Wednesday 1 February 2040 00:00″ displayed in your browser. If you’re seeing a date in the late 60’s or early 70’s, your PHP application is probably at risk from the Y2K38 bug!
What is it?
Y2K38, or the Unix Millennium Bug, affects PHP and many other languages and systems, those which use a signed 32-bit integer to represent dates. 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 number.
So it is 28 years away and I’m sure you think it’s crazy to worry about it now. However, developers thought that way about the Millennium bug in the 1970’s and 80’s.
The worst thing is any web application which handles long-term future events could be at risk. For example, a typical mortgage runs for 25 years. Pensions and savings plans can be far longer, these are all going to be affected unless something is done first. The good thing is that it is very easy to fix.
The Future is 64Bit
The future of all computers is 64Bit, yes and without doubt servers and web applications should be going that way to. If you are a lucky one to already be running under the 64Bit architecture with a 64Bit complied PHP then you are actually fine.
The reason 64Bit works is that a signed 64Bit number gives a maximum future date which is 21 times greater than the current age of the universe, 292 Billion Years.
You can probably sleep well if you know your financial application is going to be running on a 64Bit system.
Changing systems sounds like hard work, is there an alternative?
Yes! Fortunately the smart people at PHP introduced a new DateTime class in version 5.2, DateTime does not suffer from Y2K38 problems and will happily handle dates up to December 31, 9999. I might have paid off my Student Loan or Mortgage or by then!
<?php
//the date to test
$thedate = ’2040-02-01′;
//Create a new DateTime String introduced in PHP 5.1
$mynewdate = new DateTime($thedate);
//lets print the result
echo ‘<p>’, $mynewdate->format(‘l j F Y H:i’), ‘</p>’;
?>
It may not be worth upgrading existing applications, but you should certainly consider the DateTime class when planning your next project.
(Edit, Variable bug in second script.)
Given the frantic pace of iterations that web software tends to go through I’d be extremely surprised if there are *any* “legacy” PHP systems in existence in 2038 that were written today.
Good call Mr Fraser. I would expect PHP developers to be well aware of the beneficial approaches of software with objects my now, or at least, before 2038.
Yeah but it’s HOW hard to get people to stop using IE6?… I’m sure someone somewhere will get it in the back-end when the time comes. And the rest of humanity will have a chuckle at them.
Lets hope that by the time it comes around people will be well educated in proper coding and theres nothing using the ‘Legacy’ languages from today.
Still Interesting though, the fact 32bit and programming does infact have an expiration date.