By Craig Buckler

Is Your PHP Application Affected by the Y2K38 Bug?

By Craig Buckler

I don’t want to be too alarmist, but try running the following PHP code on your system:

$date = '2040-02-01';
$format = 'l d F Y H:i';

$mydate1 = strtotime($date);
echo '<p>', date($format, $mydate1), '</p>';

With 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 may be at risk from the Y2K38 bug!

What’s the Y2K38 bug?

Y2K38, or the Unix Millennium Bug, affects PHP and many other languages and systems 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 the epoch.

Yes, it’s 28 years away and I’m sure many of you think it’s ridiculous to worry about it now. However, developers thought that way about the Millennium bug the 1970’s and 80’s. Also, 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.

Will 64-bit save us?

Probably. If you’re using a 64-bit OS with a compiled 64-bit edition of PHP, your application shouldn’t be affected. I’d recommend you test it, though. A signed 64-bit number gives a maximum future date which is 21 times greater than the current age of the universe — 292 billion years, give or take a day or two.

You can probably sleep at night if you’re convinced your financial application will always be installed on a 64-bit system.

Are there alternative options?

Fortunately, PHP introduced a new DateTime class in version 5.2 (experimental support was available in 5.1 and be aware that some methods were introduced in 5.3)…

$date = '2040-02-01';
$format = 'l j F Y H:i';

$mydate2 = new DateTime($date);
echo '<p>', $mydate2->format($format), '</p>';

DateTime does not suffer from Y2K38 problems and will happily handle dates up to December 31, 9999. I might have paid off my mortgage by then!

It may not be worth upgrading existing applications, but you should certainly consider the DateTime class when planning your next project.

Has you experienced Y2K38 problems in your application? How did you fix it?

  • himeldad

    A little known event occurred in October, 2000, I believe. That was the UNIX be-linnium. On that date, the UNIX seconds hit the one billion mark. No one really paid much attention to that event :))

    • Chris

      We had an issue when that happened due to session codes in our e-commerce system (which had been coded a couple of years earlier) being partly generated from the timestamp the session started.
      Unfortunately we allocated just enough space in the database for the session code varchar to cover the length of the timestamp before they hit the billion mark in the early versions of our app. After whatever date it was, the sessions stopped working because the code being sent never matched one in the database.
      It was an easy fix by simply increasing the size of the field but it shouldn’t have happened in the first place. It goes to show how easy it can be to overlook this sort of stuff.

  • Programmers will also see problems if they store epoch time, in their databases as a 32bit signed integer.

    Prepare now, and store as a 64 bit integer

  • Quick! Time’s running out!

    hehe, isn’t this article a little premature?

    • Not necessarily. What if you want to calculate your age at a future event, store a retirement date, define a final mortgage payment, etc.

      Fixing the issue may not be important at this time but knowing about it is essential.

    • Mr T

      “isn’t this article a little premature?” [TomB]

      It sure is premature. Just like checking on whether the seatbelts in your car work if you don’t plan to have a crash ….

      The odds are that you will get to the stage where your code needs to cope with a date after January the 19th 2038 (which is now less than 28 years away). Whether that’s because you need a future date now, your existing applications will still exist and be in use then, or if a lazy developer copies large chunks of your code / uses an existing function etc. to create a future version of your app (or one similar to it).

      Pity the developer who has the rush job of going through all apps in 2037 because everyone’s put it to the back of their minds in the meantime.

  • By 2038 or whenever, we’ll be using php v20, and the date function will have been fixed!

    • Yes, of course, but what about your today application ? If it’s still running on a server that’s not been updated ?
      If you use the corrected function you don’t rely on any presumption.

  • Arghhh… my personnal system and my main housing are infected…
    Fortunately, the PHP compiled is 5.2.

  • kelvinj

    > However, developers thought that way about the Millennium bug the 1970’s and 80’s

    Everyone went apeshit in ’99 freaking out about the Y2K bug and, in the end, not much happened.

    So the lesson to learn from Y2K is that it’s ok to ignore it. if it’s still a problem in 25 years time, we’ll freak out for a while, and just deal with it. Worst case: someone will get a weird date on their bill.

    • in the end, not much happened

      But was that because the majority of problems were fixed?

      In some ways, Y2K38 is worse. It’s not as obvious, more difficult to find, harder to fix, and will effect any system using the Unix-like timestamps (such as embedded hardware).

      Weird bill dates are the least of our problems!

  • It’s not just PHP – all *NIX and whatever software run on them may have problems. A lot of code needs to be fixed, as just one bit that gets forgotten about could be cataclysmic. Nice to see PHP has taken steps towards that goal anyway.

    Pertinent question: has anyone looked at how expensive it is to use DateTime and similar classes in place of procedurals like date() and strtotime(), which some of my code is pretty well riddled with? I’m guessing there’s some cost, but how much?

  • EnnioWolsink

    headbank: DateTime creates an object, which takes a bit longer to process than a single date() function call. On the other hand, being able to use things like Datetime::modify(‘+1 month’) makes it so much better than date() and mktime(). Plus it doesn’t suffer from this Y2K38 problem of course.

    Keep in mind when implementing the DateTime class that the modify() method doesn’t automatically recognize the last day of a month nor realizes how special 29 February is.

    • Carstonio

      Is the DateTime constructor Y2K38-safe in getting the current date? I want to use it to replace the date() function for that purpose. How would DateTime compensate for the 32-bit timestamp problem?

      • Yes, DateTime does fix Y2K38 problems. It doesn’t use a 32-bit signed integer to store dates so it’s not affected by the problem.

        Remember that it’s PHP5.2+ only.

  • valentin

    It works this way (which should be the preferred way to convert date and time):

    echo date_format(date_create($date), $format);
    => Wednesday 01 February 2040 00:00

  • jaco.nel007

    I have added a discussion on the forum with tag Y2K38. I would appreciate any comments on this.

  • Learned something today… Thanks Craig!

  • Andy Robinson

    65% of voters won’t worry until 2037?! Wasn’t expecting that amount of ignorance.

  • I voted “Yes, I’ll fix it”, as in “Yes, I’ll fix it… by getting a 64 bit version of PHP, as soon as the developers think it’s stable and make an official non experimental release.”.

    By the time we reach 2038, everything will be 64 bits. The majority of software we use already has 64 bit versions available. PHP and Flash are one of the few remaining exceptions that will hopefully have 64 bits in the next 28 years.

    If they don’t, I’ll start using stuff like the DateTime class in 2037.

  • very informative and useful example. The article is very simple to understand

  • Dinosaur

    in the year of 2038 there will exist a 256bit system :D. PHP is a dinosaur language like COBOL today on that year. Is John Titor said about it? :). Nowadays, I will fix Y2K38 to my current application, because of required calculation to more than 30 years from now.

  • Jamie

    The Y2K bug caused issues with companies who bought software in 1970 and did not upgrade.
    A company not upgrading a piece of software as it would cost them money and currently works is different to a website.

    If I left my website, I doubt I would still get visitors in 1930 (hell probably even in 1920) as websites need to be constantly maintained and upgraded

    1938, the website would have been recoded god knows how many times and I will not be running PHP V4, if my hosting company have not upgraded from PHP4 in 20 years, I am not going to host with them.

  • Jason

    @Jamie – 1920? 1930? 1938? I think you’re already suffering from this bug.

  • Thank you much!
    We find it really useful, since no matter if you’re gonna fix it now or not, you’d better know about it that be caught by surprise!

    p.s. People like you, Craig, will prevent planet from dying one day ;)

  • Erik

    This bug caused issues relating to fixed income maturity dates in a trading application I develop / maintain. Thanks for the article! Couldn’t figure it out…

  • caminomaster

    Very good article. I’ve never had this bug, but is important to applications with dates in the future. Good thing to remember.

Get the latest in Front-end, once a week, for free.