源碼分析

通過查看源碼可以看到問題所在。
首先，Date類方法getMillisOf()的第一個(gè)if判斷中date不為空，但是isNormalized()返回true。這個(gè)normalize是CalendarDate中的私有屬性，只要調(diào)用過set/add之類修改時(shí)間的方法就會(huì)變成false。其他說明請(qǐng)看cdate的注釋。
其次，Date構(gòu)造方法直接將系統(tǒng)的毫秒級(jí)別的long數(shù)值賦給了fasttime。
再來，Timestamp構(gòu)造方法截取秒級(jí)的時(shí)間存入fasttime, 將毫秒微妙計(jì)入nanos中。

調(diào)試分解

然后我們對(duì)比下new Date() vs new Timestamp(System.currentTimeMillis())
兩者存儲(chǔ)方式的區(qū)別通過下面兩個(gè)圖就可以清楚分辨，只要注意fastTime。

• Date fastTime的最后三位是956，說明是精確到毫秒的

• Timestamp的最后三位是000，說明被截取到秒，而真正的毫秒166被放到nanos中了

結(jié)論說明

1. 錯(cuò)誤的根源是混用了Date 和 Timestamp, 導(dǎo)致日期比對(duì)失效。
   ORM從數(shù)據(jù)庫中取出的時(shí)間類型是Date first(見文末圖），而當(dāng)前的時(shí)間戳獲取方式錯(cuò)用了Timestamp second(見文末圖), 只要修改為new Date() 就可以了。

2. 如果無法避免混用，那就不要使用after() before()做日期對(duì)比！
   直接用 getTime() 比較long的大小即可！有興趣的同學(xué)可以看下Timestamp getTime()的源碼, 它會(huì)把nanos拼裝回?cái)?shù)值中！

如何重現(xiàn)

兩個(gè)long類型的數(shù)據(jù)，一個(gè)800毫秒，一個(gè)900毫秒，可以看出after（before類似， compareTo慎用）返回的結(jié)果是錯(cuò)誤的。

public static void main(String[] args) throws IOException {
    Date d = new Date(1473247063800L);
    Date t = new Timestamp(1473247063900L);
    System.out.println(d.getTime());
    System.out.println(t.getTime());
    System.out.println(t.after(d));  //false, 錯(cuò)誤結(jié)果
    System.out.println(t.compareTo(d));  //1, 正確結(jié)果...Timestamp的compareTo方法被重載了所以這里沒問題。
    System.out.println(d.compareTo(t));  //1, 錯(cuò)誤結(jié)果...Date的compareTo方法還是錯(cuò)誤的。
    System.out.println(t.getTime() > d.getTime()); //true, 正確結(jié)果
}