2038 年的错误遍布整个网络，但这似乎是一个 unix 问题。这将如何影响 java Date ？
问问题
6384 次
5 回答
30
是什么让你认为它确实有效？Java 的Date类存储 64 位long（不是 32 位，与 Y2K38 一样）。它还存储毫秒，这会减少范围，但只是略微（相当于约 10 位）。
在 Java 中，我们有 292278994 年的错误。
于 2010-11-30T12:28:40.047 回答
4
Java 和时间不仅限于 Date 类。
日期/时间通常来自哪里？通常来自 System.currentTimeMillis，这是一个本地方法。它通常不在 Java 中实现。返回类型是 long，但这意味着很少，因为本机方法可以返回任何适合 long 的值。
这一切都取决于操作系统及其 JRE 的实现。
依赖 64 位系统的存在可能是幼稚的，因为显然有许多嵌入式系统是 32 位的，并且将继续存在。
一般来说，Java 暴露于 2038 问题。
于 2013-01-24T23:33:43.723 回答
4
对于程序员而言，我认为它不会影响 Java Date 类。它已经在使用 64 位值。如果您使用的数据存储仍然使用 32 位值，我可以看到这是一个问题。我不希望在 27 年内看到太多 32 位操作系统。
于 2010-11-30T12:34:10.903 回答
0
This is not really an answer. But some posts have gotten it right. Java is 2038 compliant, but not 10000 compliant (if you put a long into the Date constructor that represents something after 9999, it will not work and return some weird number), but yes, 2147483648 is definitely not the maximum allowed value in Java's Date class.
于 2013-03-26T20:39:53.423 回答
-1
这可能是 2038 年日期数据类型翻转的旧 C 时代的遗留物。可能是一些非常老的应用程序的问题，但不是 Java。打哈欠。
于 2010-12-01T16:47:31.940 回答