GameCube、Wii 和 Wii U 是否容易受到 2038 年問題的影響？
2038 年問題是許多使用 2 32整數來跟踪秒數的嵌入式系統中的一個問題。基本上，一旦 2038 年 1 月 19 日發生，溢出就會將相信的“目前時間”追溯到 1901 年 12 月 13 日。
我很好奇 GameCube 是否容易受到這個問題的影響，如果是的話，Wii 和 Wii U 是否也是如此（因為我相信它們使用了很多相同的硬體）。我會問“所有任天堂系統”，但這個問題太寬泛了。
“2038 年問題”與大多數 Unix/Linux 系統將時間戳儲存為自 1970 年以來的秒數這一事實有關。這樣，帶符號的 32 位值將在 2038 年溢出。
Gamecube 和 Wii（我不確定 WiiU，但我懷疑它會是一樣的）都將它們的時間儲存為自 2000 年以來的秒數的無符號整數（
$$ 1 $$)，所以它會在 2136 年溢出。Wii 上的某些時間戳使用 64 位值表示自 2000 年以來的毫秒數；那甚至會在以後溢出。($$ 2 $$) Wii 系統菜單不允許您設置晚於 2050 年的日期，因此您可能會在那時遇到麻煩。但是 Wii 和 Gamecube 並不是真正依賴適當系統時間的系統。如果在 2050 年控制台由於時間而出現任何問題，您可以將日期設置回 2000 年，並忍受控制台在其主菜單上顯示的日期錯誤的事實。除此之外，日期錯誤不會造成任何問題。
至於像《動物森友會》這樣依賴系統時間的遊戲，遊戲唯一依賴的就是時間在前進。您可以將時間設置回幾年，遊戲將繼續執行。
像 Wiimmfi 這樣的定制線上服務目前強制控制台上設置的時間是正確的，但這是在伺服器端完成的，如果 Wiimmfi 仍然在 2050 年左右，將不再強制執行。
資料來源：
$$ 1 $$Dolphin Emulator 原始碼EXI_DeviceIPL.cpp和EXI_DeviceIPL.h發生從 Unixtime 到 Wii 時間的轉換，反之亦然 $$ 2 $$使用 64 位毫秒時間戳的 Mario Kart Wii 範例，同樣基於 2000-01-01: MKWii Network Protocol - SELECT。
據我了解，任何 32 位系統都會遇到此問題。檢查您標記的三個控制台中的每一個的 Wiki 頁面，它們都使用 32 位處理器。因此，他們執行的是 32 位系統，可能會遇到此問題。
但是，我認為他們只有在使用Unix Time 系統來跟踪時間時才會遇到問題。我認為，如果您手動將時間設置在 1970 年 1 月 1 日 00:00:00 UTC 和 2038 年 1 月 19 日 03:14:07 UTC 之間*，*即使在 2038 年之後（我不是確定控制台是否會讓您將時間設置為如此極端）。我知道最近，如果您將手機的日期設置為 1970 年 1 月 1 日 00:00:00 UTC ，您可能會導致 iPhone 崩潰。以此為例，如果您將控制台時鐘手動設置為“安全”的地方，我認為它們應該仍然可以工作。