当前位置：首页 > 问答 > 正文

Oracle各种版本驱动里头，Java Date到底咋用才不出错呢？

瞿欣合
问答
2026-01-19 04:55:43
1

这个问题问得非常核心，是无数Java程序员在用JDBC连接Oracle数据库时都会掉进去的坑，问题的根源在于：Java中的java.util.Date和java.sql.Date是一个设计上就“含义模糊”的类，而Oracle数据库对日期和时间有非常明确的类型区分。 再加上Oracle JDBC驱动版本的历史演变,就更容易混乱了。

要不出错，关键不是死记硬背一条规则，而是理解背后的原理,下面我们分版本和场景来说清楚。

理解核心矛盾：Java的Date vs. Oracle的Date

Java这边的“糊涂账”：
- java.util.Date这个类，其实同时包含了日期（年、月、日）和时间（时、分、秒、毫秒）信息,你可以把它理解为一个完整的时间戳。
- java.sql.Date是java.util.Date的子类，但它被“阉割”了，为了迎合SQL标准，它强制规定只关心日期部分（年、月、日），而把时间部分（时、分、秒、毫秒）全部强制设置为0。但这里有个大坑：当你打印一个java.sql.Date时，它的toString()方法确实只显示日期（如：2023-10-27），但它的对象内部仍然继承了对时间部分的存储能力,只是被驱动或JDBC层处理了。
Oracle那边的“精细账”：
- DATE类型：这是Oracle最早期的日期类型。重要误区：Oracle的DATE类型不仅包含日期（年、月、日），还包含时间（时、分、秒）！ 它不存储毫秒。
- TIMESTAMP类型：这是Oracle后来引入的更精确的类型，它包含日期和时间,并且可以存储到纳秒级别的精度。
- TIMESTAMP WITH TIME ZONE 和 TIMESTAMP WITH LOCAL TIME ZONE：这两个还带有时区信息,更复杂。

矛盾点就来了： 当你试图用一个只关心日期的java.sql.Date去映射Oracle那个既关心日期又关心时间的DATE字段时，时间部分应该怎么处理？反过来也一样,这种映射的不一致是很多错误的源头。

Oracle JDBC驱动的版本差异（thin驱动）

驱动版本是决定如何处理这种映射的关键，根据Oracle官方文档和广泛的社区实践,可以大致划分一个界限：

Oracle 11g 及更早版本的驱动（如ojdbc5.jar, ojdbc6.jar）：
- 默认情况下，驱动在java.sql.Date和Oracle DATE类型之间进行映射时，会“丢失”时间信息。
- 从Java写入Oracle数据库 如果你有一个java.util.Date对象，它包含时间（比如2023-10-27 14:30:25），你直接把它塞进PreparedStatement：
```
java.util.Date utilDate = new java.util.Date(); // 包含当前时间
preparedStatement.setDate(1, new java.sql.Date(utilDate.getTime()));
```
  驱动会把它转换成java.sql.Date，时间部分会被置为0，写入Oracle的DATE字段后，时间就变成了2023-10-27 00:00:00，这就是常见的“时间丢失”bug。
- 从Oracle读取出Java 如果Oracle DATE字段里存的是2023-10-27 14:30:25，你用ResultSet.getDate()来取：
```
java.sql.Date sqlDate = resultSet.getDate("date_column");
```
  你得到的sqlDate对象，其时间部分也是00:00:00,原始数据的时间信息在读取过程中就被驱动丢弃了。
Oracle 12c 及以后版本的驱动（如ojdbc7.jar, ojdbc8.jar, ojdbc10.jar等）：
- 驱动的行为发生了重要变化！为了更精确地映射，默认行为改为：java.sql.Date 会努力保持时间部分。
- 同样的写入场景： 用setDate()方法，驱动会尝试将时间信息也写入Oracle的DATE字段，这样，2023-10-27 14:30:25就能完整地存进去。
- 同样的读取场景： 用getDate()方法，驱动会从Oracle的DATE字段中把时间信息也读出来，放到java.sql.Date对象里。

注意： 即使在12c驱动中，因为java.sql.Date的toString()方法仍然只显示日期，所以你在控制台打印出来可能还是看不到时间，但如果你用getTime()方法获取毫秒数，或者用ResultSet.getTimestamp()去读,就能发现时间部分是存在的。

保证不出错的“黄金法则”

了解了这些坑和版本差异后，无论你用哪个版本的驱动，最安全、最不容易出错的做法是：

彻底弃用java.sql.Date，全面拥抱java.time包（JDK 8及以上）和java.sql.Timestamp。

对于JDK 8及以上用户（强烈推荐）：
- 使用java.time.LocalDateTime对应Oracle的DATE或TIMESTAMP（不带时区）。
- 使用java.time.LocalDate对应只关心日期的字段。
- JDBC驱动从ojdbc8开始,直接支持这些现代类型。
- 写法：
```
// 写入
LocalDateTime now = LocalDateTime.now();
preparedStatement.setObject(1, now);
// 读取
LocalDateTime time = resultSet.getObject("date_column", LocalDateTime.class);
```
- 这样做的好处是类型清晰，语义明确，完全避免了老Date类的所有历史遗留问题,这是终极解决方案。

如果必须使用老式API或JDK 7及以下：

统一使用java.sql.Timestamp。
java.sql.Timestamp也是java.util.Date的子类，但它明确设计用来存储日期和时间（含纳秒），它能与Oracle的DATE和TIMESTAMP类型进行完整映射,在所有版本的驱动中都能保持时间信息。

写法：

// 写入：无论是 utilDate 还是 sqlDate，都转成 Timestamp
java.util.Date utilDate = new java.util.Date();
preparedStatement.setTimestamp(1, new java.sql.Timestamp(utilDate.getTime()));
// 读取：一律用 getTimestamp
java.sql.Timestamp timestamp = resultSet.getTimestamp("date_column");
// 如果你需要 java.util.Date，可以直接赋值，因为Timestamp是它的子类
java.util.Date safeDate = timestamp;