对于数据库的日期字段，一般会使用Date类型，比如下面的这个建表语句：
CREATE TABLE `record` (
`id` BIGINT UNSIGNED NOT NULL PRIMARY KEY PRIMARY KEY AUTO_INCREMENT
COMMENT '自增id',
`operator_id` BIGINT UNSIGNED DEFAULT 0
COMMENT '操作者id',
`operator_name` VARCHAR(128) NOT NULL
COMMENT '操作者名字',
`date` DATE NOT NULL
COMMENT '日期', #2017-03-23 方便按天查询
)
ENGINE = InnoDB;
在编写和这个date对应的model的时候，一般会使用sql.Date。比如下面这样：
@Data
public class Record {
private long id;
private long operatorId;
private String operatorName;
java.sql.Date date; //使用sql.Date 类型
}
这样，在数据的写入和查询时，都不会有任何问题。但是最近，我们把sql.Date切换成了util.Date，如下面这样：
@Data
public class Record {
private long id;
private long operatorId;
private String operatorName;
java.util.Date date; //使用util.Date 类型代替sql.Date
}
切换成util.Date后，在插入数据和查询时也没有问题，但是在比较date字段的时候，发现了一个诡异的问题。如下面代码：
Date today = new Date();
Record record = dao.getByDate(...);
if (record.getDate().equals(today)) { //false
...
}
为了定位这个问题，我们首先怀疑是RowMapper映射的时候绑定出了问题，将sql.Date的值绑给了util.Date，引发不相等。
我们先来看sql.Date的源码。看它和util.Date有什么区别，如下：
public class Date extends java.util.Date {
....
}
sql.Date继承自util.Date，而且没有override equal的实现，我们可以看一下util.Date的equals方法的实现：
public boolean equals(Object obj) {
return obj instanceof Date && getTime() == ((Date) obj).getTime();
}
可以看到，如果是sql.Date和util.Date做equal比较，那么应该是相等的。所以问题应该不是sql.Date和util.Date类型不同造成的。
我们继续怀疑RowMapper绑定的时候做了特殊处理，那么继续看RowMapper的实现，我们在JdbcUtils里发现下面的代码( org.springframework.jdbc.support.JdbcUtils)：
else if (java.sql.Date.class == requiredType) {
return rs.getDate(index);
}
else if (java.sql.Time.class == requiredType) {
return rs.getTime(index);
}
else if (java.sql.Timestamp.class == requiredType || java.util.Date.class == requiredType) {
return rs.getTimestamp(index);
}
可以看到，在把sql.Date绑定到util.Date时，触发了这段逻辑：
else if (java.sql.Timestamp.class == requiredType || java.util.Date.class == requiredType) {
return rs.getTimestamp(index);
}
换句话说，我们model里的util.Date被绑定上了一个sql.Timestamp类型，我们来看sql.Timestamp的实现：
public class Timestamp extends java.util.Date {
...
public boolean equals(java.lang.Object ts) {
if (ts instanceof Timestamp) {
return this.equals((Timestamp)ts);
} else {
return false;
}
}
}
这里可以看出，如果是timestamp类型和util.Date类型做比较，则一定会返回false。
至此，问题定位。
对于这个问题的反思，我觉得主要有几点：
1 java的date类型的整体设计，确实非常不好，里面的各种逻辑非常混乱，比如Date可以保存时分秒，还有时区引起的其他坑等等，因此应该尽量的避免使用util.Date类型
2 对于model层使用时间，如果确实有Date类型的需求，请使用sql.Date，不要使用util.Date。sql.Date在使用过程中的表现基本是一致的，而且屏蔽了时分秒的问题
3 如果数据库在设计中有夸时区的可能，应尽量避免使用Date类型，而是保持一个long的时间戳，在业务层屏蔽混乱的Date类型
