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