在此前，遇到过使用Ibatis操作Oracle时时间精度丢失的问题，昨天又遇到JDBC操作MySQL时间字段的问题，从网上看到各种式样的解释这些问题的博文/帖子，但多是雾里看花，不得要领。
理解JDBC中的时间类型
java.sql包中包括三个类，Date, Time, 和 Timestamp，分别用来表示日期（无时间信息，eg: YYYY-MM-DD），时间（只处理时间，无日期部分, eg: HH:MM:SS）和时间戳（精确到纳秒级别）。在 它们都继承自java.util.Date。java.sql.Date和java.sql.Time都存有一个时间域，该时间域是精确到秒级别的，但是，他们只处理日期或者时间部分。在MySQL Connector/J(v5.1.13)的实现中可以看到，PrepareStatement#setDate 时会将时间重新format成”yyyy-MM-dd”格式。
因为历史遗留以及各种数据库本身的不同，各种JDBC实现中留下了格式各样的花招, 某些特殊场景下不遵照此情况可能也能工作，但不推荐这样做。
你必须根据你的实际需要来选择不同的类型，通常应该选用精确度与相应的数据库字段类型相比相同或者更高的JDBC类型。
除此以外，还可以使用java.uitl.Date类型来处理时间。java.util.Date类型是上面各个类型的父类型，JDBC的API大都可以使用。
除此以外，在JDK1.6之前版本的构造java.sql.{Date|Time|TimeStamp}对象时存在性能问题，尤其是在多线程环境下更严重。这个Bug在这里。其原因是java.util.Date的相关方法调用了TimeZone.getDefaultRef()，而此方法是同步方法注1。
MySQL的JDBC类型映射
| DATE | java.sql.Date |
| DATETIME | java.sql.Timestamp |
| TIMESTAMP[(M)] | java.sql.Timestamp |
| TIME | java.sql.Time |
| YEAR[(2|4)] | If yearIsDateType configuration property is set to false, then the returned object type is java.sql.Short. If set to true (the default) then an object of type java.sql.Date (with the date set to January 1st, at midnight). |
MySQL的DATETIME、TIMESTAMP两种字段类型的显著区别在于TIMESTAMP的取值在’1970-01-01 00:00:01′ UTC 和 ‘2038-01-19 03:14:07′ UTC之间。
MySQL在时间处理方面也有一个问题，当Datetimes类型的字段的值为0000-00-00时取值方法会得到下面的异常：
Cannot convert value ‘0000-00-00 00:00:00‘ from column xx to TIMESTAMP
这个问题的原因在于，MySQL中默认使用0000-00-00等来表示时间的特殊值（参见文档）。而在Java中，并没有一个合适的方式来表示这个时间(因为Java中时间轴上0是1970-01-01 00:00:00），早于这个时间的用负数表示，这个最小的负数在时间轴上是表示不出来的。Connector/J提供了一个属性zeroDateTimeBehavior来解决此问题。
- exception (the default), which throws an SQLException with an SQLState of S1009.（默认行为）
- convertToNull, which returns NULL instead of the date.
- round, which rounds the date to the nearest closest value which is 0001-01-01.
如下所示的jdbc连接将指定该行为转化为null值。
jdbc:mysql://localhost/myDatabase?zeroDateTimeBehavior=convertToNull
Oracle与JDBC之间的类型映射
| DATE | java.sql.Date |
| DATE | java.sql.Time |
| TIMESTAMP | java.sql.Timestamp |
Oracle数据库字段类型主要有DATE、TIMESTAMP。
在9i以后、11g以前的Oracle JDBC驱动中存在一个会丢失DATE类型字段的时间信息的bug，原因是其JDBC驱动将Oracle的Date类型处理为java.sql.Date类型，这就丢失了时间部分（看来对java.sql包下三种时间类型认识不足的问题还很普遍的）。关于这个问题，这篇帖子给出了不错的解释（墙外），此文中的方法适用于11g JDBC以前的各版本驱动。在11g JDBC驱动中，此问题已经解决了，Oracle 11g JDBC驱动的手册中也给出了解释注2。
事实上，如果是使用Ibatis，pojo属性的类型设置为java.util.Date，确保 jdbcType不为 DATE或者TIME，则避免了这个bug。因为此时Ibatis会以java.sql.Timestamp来处理该字段。我专门对此做了验证，点此看测试项目源码。
Ibatis是怎么处理日期类型的
注意：本文皆基于ibatis 2.3.4.726源码分析。不过根据我初略观察，Ibatis3也适用，但请遇到问题时有所留意。
在此前工作中碰到Oracle中的Date字段会只剩下日期部分的数据，丢失了，Google发现一些人的解决方法是将JDBCType指定为datetime。有人甚至自己编写一个自定义的TypeHandler来解决这个问题。其实这完全是瞎猫撞上死耗子，那个datetime根本没意义，却歪打正着。一般的错误都是如下的配置（或者是pojo的属性为java.sql.Date类型）：
<sqlMap namespace="Info" >
<resultMap id="Info" class="pojo.Info" >
<result column="INFO_BEGINTIME" property="begin" jdbcType="DATE" />
<result column="INFO_ENDTIME" property="end" jdbcType="DATE" />
</resultMap>
此时不论你pojo.Info中的字段类型（或者的javaType属性）是java.util.Date还是java.sql.Date，最终都会丢失数据。实际上，在pojo.Info中的字段类型(或者javaType属性）为java.util.Date时，如果指定jdbcType为DATE或TIME（区分大小写），则将分别得到DateOnlyTypeHandler或TimeOnlyTypeHandler。如果你不指定jdbcType，或者指定一个错误的值，例如datetime，或者xxxx等，都会得到DateTypeHandler（日期时间都会处理）。
如果pojo.Info中的属性类型（或者配置中的javaType属性）是java.sql.Date，则选择处理handler类时不会使用jdbcType，而是根据属性类型得到SqlDateTypeHandler（只包含日期）。
在Ibatis的手册中，指出来jdbcType一般情况下是不用于判断处理方式的注3。大部分情况下是依据javaType或者pojo属性类型来判断处理方式，在少部分无法根据pojo属性类型判断的情况下才使用。如果你用java.util.Date对应到MySQL，则就是这种少数情况之一。因为MySQL可以将多个数据库字段类型映射到java.util.Date，所以需要指定是DATE还是TIME（必须是大写），如果不指定则默认是完整的日期时间（此时按JDBC的timestamp操作）。
针对ibatis对时间的处理，我写了个测试，点此看测试代码。
对于Ibatis操作Date/Time/DateTime，总结如下：
- 将pojo的属性类型设置为java.sql.Date（或java.sql.Time, java.sql.Timestamp），此时会严格遵循这三种类型的语义。但此方法因存在前文中提到的性能问题，在JDK1.6以前的JDK版本中能少使用就少使用。
- 如果你想在pojo中使用java.util.Date， 则要注意：
- 完整的日期时间，要确保jdbcType为空，或为DATE,TIME以外的值
- 只需要时间，要指定jdbcType=”TIME”
- 只需要日期，要指定jdbcType=”DATE”
注释
注释1：Use oracle.sql.DATE or oracle.sql.TIMESTAMP rather than
java.sql.Date or java.sql.Timestamp if you are using JDK 1.5 or earlier versions or require maximum performance. You may also use the oracle.sql data type if you want to read many date values or compute or display only a small percentage. Due to a bug in all versions of Java prior to JDK 1.6, construction of java.lang.Date and java.lang.Timestamp objects is slow, especially in multithreaded environments. This bug is fixed in JDK 1.6.
注释2：Mapping SQL DATE Data type to Java Oracle Database 8i and earlier versions did not support TIMESTAMP data, but Oracle DATE data used to have a time component as an extension to the SQL standard. So, Oracle Database 8i and earlier versions of JDBC drivers mapped oracle.sql.DATE to java.sql.Timestamp to preserve the time component. Starting with Oracle Database 9.0.1, TIMESTAMP support was included and 9i JDBC drivers started mapping oracle.sql.DATE to java.sql.Date. This mapping was incorrect as it truncated the time component of Oracle DATE data. To overcome this problem, Oracle Database 11.1 introduces a new flag mapDateToTimestamp. The default value of this flag is true, which means that by default the drivers will correctly map oracle.sql.DATE to java.sql.Timestamp, retaining the time information. If you still want the incorrect but 10g compatible oracle.sql.DATE to java.sql.Date mapping, then you can get it by setting the value of mapDateToTimestamp flag to false.
注释3：Ibatis 2的手册中给出的jdbcType属性的解释：属性jdbcType用于显式地指定给本属性（property）赋值的数据库字段的数据类型。对于某些特定的操作，如果不指定字段的数据类型，某些JDBC Driver无法识别字段的数据类型。一个很好的例子是PreparedStatement.setNull(int parameterIndex, int sqlType)方法，要求指定数据类型。如果不指定数据类型，某些Driver可能指定为Types.Other或Types.Null。但是，不能保证所有的Driver都表现一致。对于这种情况，SQL Map API允许使用parameterMap子元素parameter的jdbcType属性指定数据类型。
正常情况下，只有当字段可以为NULL时才需要jdbcType属性。另一需要指定jdbcType属性的情况是字段类型为日期时间类型的情况。因为Java只有一个Date类型（java.util.Date），而大多数SQL数据库有多个－通常至少有3种。因此，需要指定字段类型是DATE还是DATETIME。
属性jdbcType可以是JDBC Types类中定义的任意参数的字符串值。虽然如此，还是有某些类型不支持（即BLOB）。本节的稍后部分会说明架构支持的数据类型。
注意！大多数JDBC Driver只有在字段可以为NULL时需要指定jdbcType属性。因此，对于这些Driver，只是在字段可以为NULL时才需要指定type属性。
注意！当使用Oracle Driver时，如果没有给可以为NULL的字段指定jdbcType属性，当试图给这些字段赋值NULL时，会出现“Invalid column type”错误。
