5

The year 2038 problem is a thing in lots of embedded systems that use a 232 integer to track seconds. Basically, once January 19th 2038 happens, an overflow runs the believed "current time" back to December 13th 1901.

I'm curious if the GameCube is vulnerable to this problem, and if so, whether the Wii and Wii U also are (since I believe they use a lot of the same hardware). I would have asked "all Nintendo systems" but that's too broad a question.

  • 1
    I'm voting to close this question as off-topic because it is not a problem for at least twenty years. – Frank Oct 8 '17 at 1:06
  • 8
    @Frank It is still a relevant question from a technology perspective, and might impact the choices of long-term mass collectors or similar folks. I don't quite agree with closing it myself. – mmKALLL Oct 8 '17 at 4:06
  • 1
    Unless they're doing anything that's time dependent this shouldn't be an issue. And if they're expected to connect to another service over the internet I don't expect that service to be around that long without issuing a firmware patch. – Shadur Oct 8 '17 at 12:23
  • I expect the impact on these consoles will be minimal. Unless you're trying to play an internet-based game, the worst-case scenario is that the console's clock will be wrong (which I wouldn't think will affect functionality), and, like Shadur says, it's unlikely that internet-based games for these consoles will still have servers to talk to in 2038 (so they won't work anyway) – Steve-O Oct 8 '17 at 13:32
  • 2
    @Shadur some games are completely time based and offline. Animal Crossing for example. – LateralTerminal May 21 '18 at 19:10
4

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 in seconds since 2000, so it'll overflow in 2068. Some timestamps on the Wii use a 64-bit value for milliseconds since 2000; that would overflow even later.

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.

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.

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.

  • 8
    "any 32-bit system will experience this problem" is blatantly false. Any system that stores time in a 32 bit integer number of seconds since 1/1/1970. Not every 32 bit system will store time in that way. – Elva Oct 8 '17 at 12:11
  • 2
    @KevinvanderVelden doesn't my "However" part clear that up? – Timmy Jim Oct 8 '17 at 12:12
  • 2
    @TimmyJim No. It has nothing to do with the processor itself or whether the OS is 32-bit or 64-bit. It depends entirely on what the C/C++ library typedefed time_t as when the program was compiled. Modern C/C++ libs should be defining it as int64_t regardless of whether they're 32-bit or 64-bit. – Powerlord Oct 8 '17 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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