为何java.sql.Timestamp继承java.util.Date且equals方法违背对称性？

这确实是个初看让人满脸问号的设计——明明继承了java.util.Date，却在equals里拒绝和Date实例比较，甚至还出现了看似递归的调用？咱们来拆解背后的考量，其实核心都是为了守住Java中equals方法的两个关键契约：对称性和传递性。

先搞清楚Timestamp和Date的本质差异 #

Timestamp比Date多了纳秒级精度的存储，而Date只有毫秒级。这是一切问题的根源：两个对象如果毫秒相同但纳秒不同，对Timestamp来说是不相等的，但对Date来说是完全相等的。

为什么不能让Timestamp和Date互相equals？ #

假设我们修改equals方法，让它在遇到Date实例时调用super.equals(ts)（也就是用Date的逻辑比较毫秒），会直接触发两个严重问题：

• 对称性破坏：比如Timestamp ts = new Timestamp(123456789L); Date d = new Date(123456789L);，此时ts.equals(d)会返回true，但d.equals(ts)会返回false（因为Date的equals会先检查类型，发现ts不是Date实例就直接返回false）。这就违反了a.equals(b) == b.equals(a)的对称性要求。
• 传递性破坏：再比如Timestamp ts1 = new Timestamp(123456789L, 123); Timestamp ts2 = new Timestamp(123456789L, 456); Date d = new Date(123456789L);，如果ts1.equals(d)和d.equals(ts2)都返回true，但ts1.equals(ts2)返回false，这就打破了a.equals(b)且b.equals(c)则a.equals(c)的传递性。

现有设计的合理性 #

当前的equals逻辑看似“反直觉”，其实是权衡后的务实选择：

• 严格限制只有同类型的Timestamp实例才能比较相等，确保比较的是完整的时间戳信息（包括纳秒），避免开发者误以为比较的只是毫秒级时间。
• 彻底避免了对称性和传递性被破坏的风险，守住了equals方法最核心的契约。
• 这是对“继承但不完全兼容”的妥协：Timestamp继承Date是为了复用Date的部分功能，但因为多了纳秒属性，无法完全遵守里氏替换原则，只能在equals上做特殊处理。

补充：文档里的加粗提示 #

官方文档里的加粗提示其实就是在强调这个陷阱：Timestamp.equals(Object)方法永远不会返回true，当传入的是Date实例时。这也是在提醒开发者，不要把Timestamp和Date混在一起做相等性比较。

内容的提问来源于stack exchange，提问作者estani