java.util.Date date comparison
场景重现：
- 在mysql数据库(innodb engine)的tab表里有一个createAt字段，类型为datetime(6) 精确到毫秒。当然大家知道mysql的日期字段默认只精确到秒级的，若要到毫秒微妙可定义为datetime(6), 从5.6.4版本开始支持
- 业务接口A通过ORM框架在表中存入一条记录，这里createAt存入
2016-04-13 15:20:39.152 - 业务接口B需查到这条记录载入实体类Entity中，其中createAt属性为Date类型，值即为上方的日期。 (注：添加了
@Temporal(TemporalType.TIMESTAMP)注解，则该字段类型为Timestamp。本场景是Date) - 获取当前的系统时间, 注意这里用了Timestamp
Date now = new Timestamp(System.currentTimeMillis())
毫秒格式化字符串为 2016-04-13 15:20:39.952
你会发现多了后面的毫秒小数 952 - 调用 now.after(entire.createAt) 期望返回true, 但实际返回false！！
这样就出现了一个怪异的情形：本来先存入数据库一条带有时间戳的记录，取出来后跟当前的系统时间戳进行对比，竟然发现之前存入的时间是在未来？！
这里到底发生了什么导致
当前系统时间 .after( 之前存入的时间 ) = false?
源码分析
通过查看源码可以看到问题所在。
首先，Date类方法getMillisOf()的第一个if判断中date不为空，但是isNormalized()返回true。这个normalize是CalendarDate中的私有属性，只要调用过set/add之类修改时间的方法就会变成false。其他说明请看cdate的注释。
其次，Date构造方法直接将系统的毫秒级别的long数值赋给了fasttime。
再来，Timestamp构造方法截取秒级的时间存入fasttime, 将毫秒微妙计入nanos中。
/*
* If cdate is null, then fastTime indicates the time in millis.
* If cdate.isNormalized() is true, then fastTime and cdate are in
* synch. Otherwise, fastTime is ignored, and cdate indicates the
* time.
*/
private transient BaseCalendar.Date cdate;
public Date() {
this(System.currentTimeMillis());
}
public Date(long date) {
fastTime = date;
}
static final long getMillisOf(Date date) {
if (date.cdate == null || date.cdate.isNormalized()) {
return date.fastTime;
}
BaseCalendar.Date d = (BaseCalendar.Date) date.cdate.clone();
return gcal.getTime(d);
}
Timestamp构造方法：
public Timestamp(long time) {
super((time/1000)*1000); //毫秒除1000取整只剩下秒了，再乘以1000作为毫秒数值
nanos = (int)((time%1000) * 1000000);
if (nanos < 0) {
nanos = 1000000000 + nanos;
super.setTime(((time/1000)-1)*1000);
}
}
调试分解
然后我们对比下new Date() vs new Timestamp(System.currentTimeMillis())
两者存储方式的区别通过下面两个图就可以清楚分辨，只要注意fastTime。
- Date fastTime的最后三位是956，说明是精确到毫秒的
- Timestamp的最后三位是000，说明被截取到秒，而真正的毫秒166被放到nanos中了
Date.png
Timestamp.png
结论说明
- 错误的根源是混用了Date 和 Timestamp, 导致日期比对失效。
ORM从数据库中取出的时间类型是Datefirst(见文末图），而当前的时间戳获取方式错用了Timestampsecond(见文末图), 只要修改为new Date() 就可以了。 - 如果无法避免混用，那就不要使用after() before()做日期对比！
直接用 getTime() 比较long的大小即可！有兴趣的同学可以看下Timestamp getTime()的源码, 它会把nanos拼装回数值中！
debug.PNG
如何重现
两个long类型的数据，一个800毫秒，一个900毫秒，可以看出after（before类似， compareTo慎用）返回的结果是错误的。
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, 错误结果
System.out.println(t.compareTo(d)); //1, 正确结果...Timestamp的compareTo方法被重载了所以这里没问题。
System.out.println(d.compareTo(t)); //1, 错误结果...Date的compareTo方法还是错误的。
System.out.println(t.getTime() > d.getTime()); //true, 正确结果
}