应使用 ja va.sql.Timestamp 或 JDBC 4.2+ 的 LocalDateTime 存储带时间的值
在Ja va应用与Oracle数据库交互时，一个相当经典的“坑”就是时间数据的存储。很多开发者会发现，明明代码里传了一个包含时分秒的时间点，存进数据库再查出来，时间部分却莫名其妙地变成了“00:00:00”。这背后，往往是对 ja va.sql.Date 的误解所致。
ja va.sql.Date 存进 Oracle 后时间部分全变成 00:00:00
问题的根源在于类型误用：试图用 ja va.sql.Date 来存储一个完整的、带有时分秒的时间戳。这从根本上就错了。这个类的设计初衷，就是**仅表示SQL标准中的DATE类型，即年月日**。它并非一个通用的“Ja va日期时间”容器。
常见的错误场景是这样的：通过 new ja va.sql.Date(System.currentTimeMillis()) 创建一个对象，然后插入到Oracle的 DATE 或 TIMESTAMP 字段。或者，将一个包含时间的 ja va.util.Date 对象通过 PreparedStatement.setDate() 方法设置进去。结果呢？查出来的时间永远是午夜零点。
- 虽然
ja va.sql.Date继承自ja va.util.Date，但它的语义被严格限定为“日期”。它在构造时，就会将内部的时间部分（时、分、秒、毫秒）强制归零，只保留年月日信息。 - 它的
toString()方法被重写，输出格式类似2024-05-20，这进一步强化了它“只有日期”的假象。但其底层存储的毫秒值，对应的正是当天00:00:00的时间戳。 - 这里需要澄清一个关键点：Oracle数据库的
DATE类型，实际上包含了年、月、日、时、分、秒（精度到秒）。而TIMESTAMP类型精度更高（可达纳秒）。也就是说，数据库字段本身是完全可以存储时间的。问题出在Ja va端——你传入的数据在构造时就已经被“阉割”了。
该用 ja va.sql.Timestamp 还是 LocalDateTime？
那么，正确的姿势是什么？这取决于你使用的JDBC版本，以及对时区语义的需求。
假设你的业务场景是存储诸如订单创建时间、日志记录点这类需要精确到秒甚至毫秒的时间戳。
- JDBC 4.2+（JDK 8及以上版本默认支持）：这是目前推荐的方式。直接使用
ja va.time包下的LocalDateTime（无时区）或ZonedDateTime（带时区）。在设置参数时，调用PreparedStatement.setObject(1, localDateTime)即可。现代驱动会自动将其映射到Oracle的TIMESTAMP类型。 - 老版本JDBC（例如使用ojdbc6驱动）：这时必须使用
ja va.sql.Timestamp。它是ja va.util.Date的子类，**明确保留了毫秒级的精度**，对应Oracle的TIMESTAMP字段。 - 记住一个原则：绝对不要用
ja va.sql.Date存储任何带时间的值。同样，也不要直接将ja va.util.Date对象传给setDate()方法，因为它会被JDBC内部转换为ja va.sql.Date，从而导致时间部分丢失。
PreparedStatement.setTimestamp() 的三个参数怎么选？
当使用 ja va.sql.Timestamp 时，会碰到 setTimestamp 方法有两个版本：两参数和三参数。那个三参数的方法 setTimestamp(int parameterIndex, Timestamp x, Calendar cal) 尤其容易在跨时区场景下被误用。
参数差异和实际影响如下：
- 两参数版
setTimestamp(1, ts)：JDBC驱动会使用当前JVM的默认时区来解释ts这个时间戳所代表的“本地时间”，然后将其转换为数据库服务器所在的时区进行存储。如果应用服务器（JVM）和数据库服务器的时区设置不一致，写入的时间值就可能发生意想不到的偏移。 - 三参数版
setTimestamp(1, ts, cal)：你可以通过Calendar参数显式地指定一个时区。驱动会使用这个指定的时区来解析ts。例如，传入一个UTC时区的Calendar实例，就意味着告诉数据库：“请把这个ts当作UTC时间来理解并存储”。这在处理全球化、多时区应用时至关重要。 - 关于性能：三参数版本因为多了一次时区转换计算，开销略大，但换来了对时间语义的精确控制。两参数版本虽然简单，但其行为依赖于运行环境的时区配置，这在部署后可能因服务器环境变更而引入难以排查的错误。
Oracle 字段类型选 DATE 还是 TIMESTAMP？
最后，我们回到数据库层面。Oracle的 DATE 和 TIMESTAMP 该怎么选？别只看名字，得看它们的实际能力和你的需求。
两者的兼容性与行为差异需要仔细权衡：
DATE：在Oracle中，其精度只到“秒”，没有小数秒部分；也不支持时区信息。当使用ja va.sql.Timestamp写入时，毫秒部分会被静默丢弃（实际上是四舍五入到最近的秒）。TIMESTAMP：默认精度是微秒（可以指定精度，如TIMESTAMP(6)表示保留6位小数秒），能很好地支持毫秒级存储。如果使用TIMESTAMP WITH TIME ZONE，还可以直接存储时区偏移量。- 还有一个细节：即使你使用了JDBC 4.2+ 的
LocalDateTime来写入Oracle的DATE字段，驱动也会自动截断毫秒部分。这个过程不会报错，但数据精度已经丢失了。 - 给生产环境的建议是：统一使用
TIMESTAMP。即使当前业务对毫秒没有要求，这也为未来的功能扩展（如更精确的审计、性能分析）预留了空间，避免了后期修改表结构的麻烦。
说到底，最棘手的问题往往不是单纯选择数据库字段类型，而是Ja va端错误的对象类型与Oracle字段类型不匹配所产生的“化学反应”。例如即使用 ja va.sql.Date 往高精度的 TIMESTAMP 字段里写，时间照样会被归零。时区、精度、驱动版本，这三者只要有一个没对齐，你存储的时间就可能在你眼皮底下悄悄“变脸”。
