2038年问题已经铺天盖地，但似乎这只是Unix的问题。那么这将如何影响Java日期？
5个回答
31
您为什么认为这样呢？Java的 Date 类存储了64位的 long（而不是像Y2K38一样32位）。它还存储毫秒数，这会减少范围，但只有轻微的影响（相当于约10位）。
在Java中，我们会遇到292278994年的问题。
- Matthew Flaschen
6
2+1 - 但是Java在Unix上有时候需要与底层操作系统交互日期。这不太可能是一个真正的问题（直到2038年），但或许值得一提。 - user180247
1@Steve，没错，但我认为这个问题特别涉及到
java.util.Date，而不涉及任何 time_t 相关的内容。 - Matthew Flaschen一个Java应用程序最初如何获取时间？Java可能能够很好地处理日期，但GIGO仍然可能是一个问题。 - BCS
@BCS - 是的，但当前日期直到2038年才会变成2038年。所以现在有什么问题呢？同样适用于例如文件日期-除非您正在与时光旅行者共享文件。因此，在2038年之前不太可能是真正的问题。 - user180247
@Steve314：我当时（现在也是）同意你的观点。 - BCS
1@BCS - 但你假设我同意自己的观点了吗？我经常扮演魔鬼的代言人。不过要注意，扮演魔鬼的代言人也有麻烦的地方... - user180247
5
Java和时间不仅局限于Date类。
日期/时间通常来自哪里？通常来自System.currentTimeMillis，它是本地方法。它通常不是用Java实现的。返回类型是long，但这意味着很少，因为本地方法可以返回任何适合长整型的值。
这将完全取决于操作系统及其对JRE的实现。
依赖64位系统的存在可能是幼稚的，因为显然有许多嵌入式系统是32位的，并且将继续存在。
总的来说，Java面临2038问题。
- John
4
我认为这不会对Java Date类造成影响，至少对程序员而言是这样。因为它已经使用了64位值。如果你正在使用仍在使用32位值的数据存储，则可能会出现问题。我不希望在27年内看到太多32位操作系统。
- JOTN
3
那些尚未修补以解决此问题的系统。我想一些嵌入式系统可能仍在使用32位。 - Peter Lawrey
1我非常确定，28年后甚至嵌入式系统也不会使用32位。 - Goran Jovic
2@Goran - 洗衣机可能仍然使用8位，就像它们现在可能做的那样。不确定在未来28年里衣服或污垢会发生多大变化。但是如果某些事情确实发生了变化（例如数字版权管理以防止您使用未经授权的洗涤剂），则可能需要32位Unix盒子。 - user180247
0
这并不是一个真正的答案。但是有些帖子已经说得很对了。Java是2038兼容的，但不是10000兼容的（如果您将一个长整型放入表示9999年之后的日期构造函数中，它将无法工作并返回一些奇怪的数字），但是，2147483648绝对不是Java Date类中允许的最大值。
- user2213307
-1
这可能是旧的C语言时代遗留下来的问题，当日期数据类型在2038年翻转时会出现问题。对于Java而言，这可能会影响一些非常老旧的应用程序，但并不是什么大问题。呵呵。
- aksarben
1
以上的答案表明，这个问题比那个更加微妙，而且Java也会受到影响，因为对于许多常见的路径，它与底层操作系统并不完全隔离。 - Derek T. Jones
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接