爲什麼Java程序員應該關心2038年的錯誤？

Question

2038年的錯誤遍佈網絡，但這似乎是一個unix問題。這將如何影響java日期？

Answer 1

是什麼讓你覺得它呢？ Java的Date類存儲64位的long（與Y2K38不同，不是32位）。它也存儲毫秒，這會減小範圍，但只是略微（相當於〜10位）。

在Java中，我們有292278994年的bug。

Answer 2

對於程序員而言，我不認爲它會影響Java Date類。它已經在使用64位值。如果您使用仍使用32位值的數據存儲，則可以看到這是一個問題。我不希望在27年內看到太多的32位操作系統。

Answer 3

這可能是2038年日期數據類型翻轉後的舊C日剩餘的時間。可能會出現一些問題，其中有一些確實是舊的應用程序，但不適用於Java。打哈欠。

Answer 4

Java和時間不僅限於Date類。

日期/時間往往來自哪裏？通常來自System.currentTimeMillis，這是本地方法。它通常不用Java實現。返回類型是很長的，但這意味着很少，因爲本地方法可以返回任何適合長整型的值。

它將全部取決於操作系統及其JRE的實現。

依賴於64位系統的存在可能是天真的，因爲顯然有許多嵌入式系統是32位的，並且將繼續存在。

通常，Java會暴露於2038年版本。

Answer 5

這不是一個真正的答案。但有些帖子正確。 Java是2038兼容的，但不符合10000（如果你在Date構造函數中放置了一段代表9999後的東西，它不會起作用並返回一些奇怪的數字），但是是的，2147483648絕對不是Java日期中允許的最大值類。