为什么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日期中允许的最大值类。