为什么 Java 程序员应该关心 2038 年 bug？
2038年的Bug遍布网络，但这似乎是一个unix问题。这将如何影响 java Date ？
Year 2038 Bug is all over the web, But this seems to be a unix issue. How will this affect java Date ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是什么让你认为它确实如此？ Java 的
Date类存储 64 位long（不是 32 位，如 Y2K38）。它还存储毫秒，这会缩小范围，但幅度很小（相当于约 10 位）。在 Java 中，我们有年份 292278994 的错误。
What makes you think it does? Java's
Dateclass stores a 64-bitlong(not 32-bit, as with Y2K38). It also stores milliseconds, which decreases the range, but only slightly (equivalent of ~10 bits).In Java, we have the year 292278994 bug.
Java 和时间不仅仅局限于 Date 类。
日期/时间通常来自哪里？通常来自 System.currentTimeMillis，它是本机方法。它通常不是用 Java 实现的。返回类型是 long，但这意义不大，因为本机方法可以返回任何适合 long 的值。
这完全取决于操作系统及其 JRE 的实现。
依赖 64 位系统的存在可能很天真，因为显然有许多嵌入式系统是 32 位的，并且将继续如此。
总的来说，Java 暴露于 2038 问题。
Java and times aren't restricted just to the Date class.
Where do dates/times often come from? Often from System.currentTimeMillis, which is a native method. It's typically not implemented in Java. The return type is a long, but that means little, since the native method can return any value that simply fits into a long.
It will all depend on the OS, and its implementation of the JRE.
To rely on the presence of 64-bit systems might be naive, since apparently there are many embedded systems that are 32-bit, and will continue to be.
In general, Java is exposed to the 2038 issue.
对于程序员而言，我不认为它会影响 Java Date 类。它已经在使用 64 位值。如果您使用的数据存储仍然使用 32 位值，我可以看到这是一个问题。我预计 27 年内不会出现太多 32 位操作系统。
I don't believe it will impact the Java Date class as for as the programmer is concerned. It's already using 64-bit values. I can see it being a problem if you're using a data store that still uses 32-bit values. I don't expect to see too many 32-bit OSes around in 27 years.
这并不是一个真正的答案。但有些帖子已经说对了。 Java 符合 2038，但不符合 10000（如果你在 Date 构造函数中放入一个代表 9999 之后的值的 long，它将不起作用并返回一些奇怪的数字），但是，是的，2147483648 绝对不是 Java 的 Date 中允许的最大值班级。
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.
这可能是旧 C 时代的遗留问题，当时日期数据类型在 2038 年更新。对于一些真正旧应用程序来说可能会出现问题，但对于 Java 来说则不然。打哈欠。
This is probably a leftover from the old C days when the date data types rolled over in 2038. Might be a problem with some really old apps, but not for Java. Yawn.