【发布时间】:2016-05-12 17:05:48
【问题描述】:
当从数据库(java.sql.Date)中读取日期时,Java 运行时返回了某种“反转”毫秒值。毫秒值与天数大致相同,但从第 0 年开始倒数。
只需重新启动 Java 运行时即可解决问题。
但是:我发现除了工作日之外,Java 几乎可以正确处理这些“反转”值。
当你运行以下代码时:
System.out.println(new java.util.Date(253402214400000l));
System.out.println(new java.util.Date(-377648784000000l));
你会得到以下输出:
Fri Dec 31 01:00:00 CET 9999
Tue Dec 31 01:00:00 CET 9999
另一个例子:
System.out.println(new java.util.Date(-294192000000l));
System.out.println(new java.util.Date(-123967324800000l));
结果:
Mon Sep 05 01:00:00 CET 1960
Mon Sep 05 01:00:00 CET 1960
使用在线转换器时,特定第二行的结果会有所不同。这将导致负日期(年份为负)接近真实的正日期:
Example1:
253402214400000 = Fri Dec 31 9999 01:00:00
-377648784000000 = Tue Oct 15 -9998 02:00:00
Example 2:
-294192000000 = Mon Sep 05 1960 02:00:00
-123967324800000 = Mon Aug 19 -1959 02:00:00
我没有找到关于这个“主题”的任何信息。
那么,“倒转”日期背后的神话是什么?为什么 Java 几乎可以正确处理它们?调用 resultSet.getDate(1).getTime() 时,JDBC ResultSet 返回“反转”毫秒值是什么意思?
【问题讨论】:
-
你说的是
java.util.Date还是java.sql.Date?意识到 JDBC 结果集的行为是特定于驱动程序的,因为每个驱动程序都为其特定的数据库实现它。 -
这是一个java.sql.Date(java.util.Date的子类)
-
我不知道你所说的“倒置”是什么意思。
-
“倒置”是指 - 如果数据库包含 1960 年以内的日期,我收到的毫秒值对应于 -1959 年的日期,或者 9999 被接收为 -9998。因此,比较 validFrom/validTo-Dates,validFrom-Dates 大于 validTo-Dates,因为毫秒值已反转。 253402214400000 返回为 -377648784000000,当转换为 Java 日期时,会导致完全相同的日期,但使用在线转换器会导致 0 年之前的相同日期。
-
java.sql.Date并不是一个很好的用于推理 Java 中日期的方法,因为toString的实现之一是java.sql.Date仅打印 4 位数的年份。
标签: java date time long-integer