11

您好，我有一个这样的代码片段：

Date d1 = new java.sql.Timestamp(new Date().getTime());
Thread.sleep(10);
Date d2 = new java.sql.Timestamp(new Date().getTime());
System.out.println("Date1: " + d1);
System.out.println("Date2: " + d2);
System.out.println("Comparing times d1.t < d2.t: " + (d1.getTime() < d2.getTime()));
System.out.println("Comparing dates d1.before(d2): " + (d1.before(d2)));

输出如下所示：

Date1: 2013-03-26 11:04:01.093
Date2: 2013-03-26 11:04:01.103
Comparing times d1.t < d2.t: true
Comparing dates d1.before(d2): false

这个 java.sql.Timestamp 类有什么问题？

是的，我看过这个：

注意：此类型是 java.util.Date 和单独的纳秒值的组合。只有整数秒存储在 java.util.Date 组件中。小数秒 - 纳秒 - 是分开的。Timestamp.equals(Object) 方法在传递 java.util.Date 类型的值时永远不会返回 true，因为日期的 nanos 组件是未知的。因此，Timestamp.equals(Object) 方法相对于 java.util.Date.equals(Object) 方法不是对称的。此外，hashcode 方法使用底层的 java.util.Date 实现，因此在其计算中不包括 nanos。

由于上面提到的 Timestamp 类和 java.util.Date 类之间的差异，建议代码不要将 Timestamp 值一般视为 java.util.Date 的实例。Timestamp 和 java.util.Date 的继承关系实际上是实现继承，而不是类型继承。

但它适用于 Date <-> Timestamp 关系。

在我的示例中，我只有时间戳，但行为仍然出乎意料..

更新：答案

发生这种情况的原因是before()方法被重载，而不是在java.sql.Timestamp. 我期待一个“覆盖”的行为。比较时间戳的正确方法是使用时间戳变量，而不是日期。

这在 Java 核心中仍然是一个糟糕的设计决策，因为继承应该意味着Timestamp is-a Date，没有惩罚和例外。

4

4 回答 4

3

Try to use Timestamp instead of Date and it will work. 

Timestamp d1 = new java.sql.Timestamp(new Date().getTime());

Timestamp and Date both have own implementation of method before. Check it.

于 2013-03-26T04:28:12.543 回答
3

好吧，这似乎是一个记录不足的功能。

的before和after方法Timestamp似乎是比较到第二个，但没有考虑到毫秒部分。尝试运行它，直到两者TimeStamp都进入不同的秒数并且比较按预期工作（将睡眠增加到 500 以使其更容易）。

顺便说一句，该compareTo方法考虑了毫秒，因此您可以改用它。

于 2013-03-26T04:16:46.437 回答
1

如果你调用方法Timestamp.before(Timestamp)，你会得到预期的结果。

但显然使用 aTimestamp作为 aDate将是一个全面的混乱。您必须静态Timestamp使用as 。Timestamp

于 2013-03-26T04:34:29.083 回答
0

正如这里提到的

时间戳是一个薄包装

时间戳只是增加了保存 SQL TIMESTAMP 小数秒值的能力（在您的情况下出现问题的地方精度为纳秒）

于 2013-03-26T05:47:09.453 回答