Just out of curiosity, what will happen to RPis Model A and B on January 19, 2038 in 3:14:07 AM GMT? Are they affected by the Y2K38 bug?

  • How many do you expect still to be running then? – Thorbjørn Ravn Andersen Dec 30 '13 at 14:34
  • 1
    @ThorbjørnRavnAndersen to be honest I believe that the RPi has big future and there will be many of them still running (eventually models C or greater but..) – DaGhostman Dimitrov Dec 30 '13 at 14:39
  • 5
    In that case, set the clock and see. – Thorbjørn Ravn Andersen Dec 30 '13 at 14:40
  • 1
    Haven't tought of that.. :D – DaGhostman Dimitrov Dec 30 '13 at 14:41
  • 1
    Whatever the future of the pi is, chances are neither it nor anything else will still be using a 32-bit processor in 25 years. As per wikipedia, 64-bit systems use a 64-bit time_t, turning this into the Y292G problem, which neither us nor the sun will live to see. – goldilocks Dec 30 '13 at 17:29


Here's the output of a SSH session to my Pi running OpenELEC.

It hangs after reaching Y2K38. Not only the SSH session itself stops responding, but OpenELEC freezes as well.

I expect (and hope!) that by 2038 a fix will have been released.

That, or your question will get a lot of upvotes in 24 years.

enter image description here

  • I'm surprised you were able to open an SSH session with a machine with such a wildly-off date. +1 for actually trying it though. – einnocent Dec 30 '13 at 16:04
  • @einnocent Why wouldn't I be able? Is there any kind of time comparision on the SSH handshaking specs that would prevent it? Besides, I have changed the time after the connection was established. Besides, the Pi clock was already wrong anyway (by a few months, years, can't recall) :P – That Brazilian Guy Dec 30 '13 at 16:06
  • Changing the time pre-connection, I understand that large differences in clock times can cause issues with some security handshakes, though I don't know about SSH in particular. With a post-connection change, I could imagine SSH suddenly freaking out upon discovering it had a connection open for 34 years. I suppose there's a small (but non-zero) chance that SSH simply ended the connection at that magic time. But really I'm convinced with your answer :) – einnocent Dec 30 '13 at 16:38
  • @einnocent It didn't occur to me that SSH could think it was "open for 24 years" and hang. I will try again with, say, 22 years. But I think it is not the cause, because it hangs exactly upon reaching Y2K38 – That Brazilian Guy Dec 30 '13 at 18:36

Actually the Raspberry Pi (hardware) will be fine. It doesn't contain a RTC, so it's going to be dependent on which OS you use.

But IIRC all 32bit version of Linux do have this issue. Sometime ago (10yrs or so) Linus said that he wasn't interesting in fixing this on 32 bit platforms and all 64bit Linux platforms at the time had 64bit time_t. He may have changed is mind since then of course. The best link to this I can find is http://permalink.gmane.org/gmane.linux.kernel/1184914 - which isn't the same , but expresses a similar intent.

It won't be a particularly difficult thing to change, but it would force a change in the the kernel ABIs. Which is a problem in itself.

But, RiscOs uses a 40bit time (centisecond), but with a different Epoch. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - I make that failling sometime in 2318 - [calc was: 1970 + ((2^40)/100 ) /(60*60*24*365.25) ]

Android, of course uses the Linux kernel. And I'm sure I've missed other options.


As is currently implemented, the Raspberry Pi will suffer the fate of the listed bug, if no changes in software are made.

Most modern machines are making the jump to 64bit processors, but I wouldn't be surprised at all to still see 32bit mainstreamed processors at that point. There are software solutions that could and will have to solve the problem.

It seems to me that the most likely fix would be to update Epoch time to start at something like January 1st, 2000. While this wouldn't delay the bug, it would certainly reset it for the foreseeable future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.