14

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?

5
  • How many do you expect still to be running then?
    – Thorbjørn Ravn Andersen
    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..)
    – DaGhostman Dimitrov
    Dec 30, 2013 at 14:39
  • 5
    In that case, set the clock and see.
    – Thorbjørn Ravn Andersen
    Dec 30, 2013 at 14:40
  • 1
    Haven't tought of that.. :D
    – DaGhostman Dimitrov
    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

Reset to default
11

Yes.

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

4
  • 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
    – That Brazilian Guy
    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
    – That Brazilian Guy
    Dec 30, 2013 at 18:36
4

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

If I remember correctly, all 32bit version of Linux have this issue. Some time ago (10yrs or so) Linus said he wasn't interesting in fixing this on 32bit platforms, and at the time all 64bit Linux platforms used 64bit time_t. He may have changed his mind since then of course. The best link I can find to this is http://permalink.gmane.org/gmane.linux.kernel/1184914 (broken link!) - 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.

RISC OS uses a 40bit time (centiseconds), but with a different epoch (https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3) and should encounter problems sometime in 2318 - [ 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.

3
  • "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).
    – That Brazilian Guy
    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
  • Commenting on my own post - but in the last 10 years, the situation for 32-bit kernels has changed and looks like they have a 64-bit time_t solution. ( lkml.org/lkml/2020/1/29/355 )
    – rgammans
    May 11, 2023 at 17:50
1

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 and acknowledge you have read our privacy policy.

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