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? Dec 30, 2013 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..) Dec 30, 2013 at 14:39
  • 5
    In that case, set the clock and see. Dec 30, 2013 at 14:40
  • 1
    Haven't tought of that.. :D Dec 30, 2013 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, 2013 at 17:29

3 Answers 3



Here's the output of a SSH session to my Pi 1 (Model B, 32 bits) running OpenELEC v3.0.6.

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, 2013 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 Dec 30, 2013 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, 2013 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 Dec 30, 2013 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.

  • "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": Well, all Pi 1 and 2 models (except Pi2 Model B v1.2) are 32-bit only. Also, Raspbian only have 32 bit releases, regardless of Pi model (there are very recent 64 bit betas, though). Jul 17, 2020 at 22:46
  • @ThatBrazilianGuy. When this comment was written there were no 64-bit models. But that a bit irrelevant, the hardware architecture, does not constrain the operating system's choice of the way to measure time. There is nothing stopping a 32bit OS not having a 64bit time_t. As I said RiscOS doesn't suffer that bug, (it comes later) even on 32bit models.
    – rgammans
    Jul 23, 2020 at 10:45

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.