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?
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.
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.