13

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.

5
  • 1
    I'm voting to close this question as off-topic because it is not a problem for at least twenty years.
    – Frank
    Commented Oct 8, 2017 at 1:06
  • 20
    @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
    Commented Oct 8, 2017 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. Commented Oct 8, 2017 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
    Commented Oct 8, 2017 at 13:32
  • 2
    @Shadur some games are completely time based and offline. Animal Crossing for example. Commented May 21, 2018 at 19:10

3 Answers 3

10

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.

2
  • Do you have any references for any of this?
    – T.J.L.
    Commented Oct 15, 2019 at 20:47
  • There probably aren't any official sources for this straight from Nintendo, but I added some sources that mention this. Commented Oct 16, 2019 at 5:27
1

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.

3
  • 12
    "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
    Commented Oct 8, 2017 at 12:11
  • 2
    @Elva doesn't my "However" part clear that up?
    – Timmy Jim
    Commented Oct 8, 2017 at 12:12
  • 3
    @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
    Commented Oct 8, 2017 at 22:48
-2

Not sure if this is related, I know this post is years old at this point but I just noticed something. I dug out my old Gamecube today for the first time in many years, plugged it in and it had to do the initial setup again. After this I checked the date and time and I noticed the date is set to the 7th February year 2136. This is especially strange as the maximum year you can set the date to in the system settings is 2099.

I would imagine this is due to the battery inside the Gamecube running out over many years, which would make sense for it to have wrapped around given what Florian said previously. Not sure if anyone has run into this before but I thought it was worth noting.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .