Are the GameCube, Wii, and Wii U vulnerable to the year 2038 problem?
Solution 1:
The "Year-2038-Problem" is related to the fact that most Unix / Linux systems store timestamps as the amount of seconds since 1970. That way, a signed 32-bit value will overflow in 2038.
Both Gamecube and Wii (I'm not sure about WiiU but I suspect it'll be the same) are storing their time as an unsigned integer with seconds since 2000 ([1]), so it'll overflow in 2136. Some timestamps on the Wii use a 64-bit value for milliseconds since 2000; that would overflow even later. ([2])
The Wii system menu doesn't allow you to set a date later than 2050, so you might run into trouble at that point. But Wii and Gamecube aren't really systems that rely on proper system time. If in 2050 there are any problems with the console due to the time, you could just set the date back to 2000 and live with the fact that the date the console displays on its main menu is wrong. Other than that, having a wrong date won't cause any problems.
As for games like Animal Crossing that rely on the system time, the only thing that game relies on is the fact that time is moving forward. You can set the time back a couple years and the game will continue to work.
Custom online services like Wiimmfi currently enforce that the time set on the console be correct, but that is something that is done serverside and will no longer be enforced if Wiimmfi is still around in 2050.
Sources:
[1] Dolphin Emulator source code EXI_DeviceIPL.cpp and EXI_DeviceIPL.h where the conversion from Unixtime to Wii time and vice versa happens
[2] Example of Mario Kart Wii where 64-bit timestamps for milliseconds are used, also based on 2000-01-01: MKWii Network Protocol - SELECT.
Solution 2:
From what I understand, any 32-bit system will experience this problem. Examining the Wiki page for each of the three consoles you have tagged, they all use a 32-bit processor. As such, they are running 32-bit systems and may experience this problem.
- Gamecube's Processor
- Wii's Processor
- Wii U's Processor
However, I think they will only experience a problem if they use the Unix Time system to keep track of time. I would think that if you manually set the time somewhere between 00:00:00 UTC January 1, 1970 and 03:14:07 UTC January 19, 2038, the system may work fine, even after the year 2038 (I'm not sure if the consoles will let you set the time to such extremes). I know that rather recently, you could have crashed an iPhone if you set the phones date back to January 1, 1970 00:00:00 UTC. Using this as an example, if you kept your consoles clock manually set to somewhere "safe," I would think they should still work.