Will RPi suffer from the Y2K38 bug?

Question

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?

@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
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

That Brazilian Guy · Accepted Answer · 2020-07-16T21:03:30.227

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

edited Jul 16 '20 at 21:03

answered Dec 30 '13 at 15:54

That Brazilian Guy

452
1
8
20

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

score 4 · Answer 2 · edited May 11 '23 at 17:48

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.

edited May 11 '23 at 17:48

Community

1

answered Dec 31 '13 at 12:06

rgammans

141
2

"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 '20 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 '20 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. ( https://lkml.org/lkml/2020/1/29/355 ) – rgammans May 11 '23 at 17:50

score 1 · Answer 3 · answered Dec 30 '13 at 16:40

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.

Will RPi suffer from the Y2K38 bug?

3 Answers3

Yes.