如何处理Oracle DATE类型在Java的精度丢失_TIMESTAMP映射与LocalDateTime支持-Oracle-PHP中文网

Java读取Oracle DATE字段秒后小数位变.0，因JDBC默认用java.sql.Date映射，仅保留年月日而截断时间；应改用getTimestamp()获取完整时分秒。

Java 读取 Oracle DATE 字段为什么秒后小数位全变成 .0？

oracle 的 date 类型实际精度到秒（不存毫秒），但 jdbc 驱动默认用 java.sql.date 映射，而这个类会强制截断时分秒、归零毫秒——哪怕数据库里存的是 2024-05-20 14:30:45，java 里拿到的也可能是 2024-05-20 00:00:00。

根本原因不是 Oracle 存错了，而是 JDBC 驱动对 DATE 的默认类型映射做了“日期语义优先”的裁剪：它只保留年月日，丢弃时间部分。

确认字段真实值：用 SQL*Plus 或 DBeaver 直查，看是否真有时间部分（SELECT TO_CHAR(col, 'YYYY-MM-DD HH24:MI:SS') FROM t）
别用 ResultSet.getDate()，改用 ResultSet.getTimestamp() —— 它能完整读出 Oracle DATE 里的时分秒
如果必须用 LocalDateTime，直接基于 getTimestamp() 转：rs.getTimestamp("col").toLocalDateTime()

Oracle TIMESTAMP 和 Java LocalDateTime 映射失败报 ClassCastException？

常见于用 MyBatis 或 JPA 时，数据库字段是 TIMESTAMP，Java 实体字段声明为 LocalDateTime，但运行时报 java.sql.Timestamp cannot be cast to java.time.LocalDateTime。

这不是类型不兼容，而是框架没配好类型处理器或驱动版本太老。Oracle 12c+ 驱动（ojdbc8.jar）原生支持 LocalDateTime，但需要显式启用。

检查驱动版本：必须是 ojdbc8（对应 JDK 8+），ojdbc6 或 ojdbc7 不支持 JSR-310 类型
连接 URL 加参数：?oracle.jdbc.javaTimeSupport=true（某些旧版驱动需此开关）
MyBatis 中若仍报错，加全局配置：<typehandler handler="org.apache.ibatis.type.LocalDateTimeTypeHandler"></typehandler>
JPA（Hibernate）需在 application.properties 加：spring.jpa.properties.hibernate.jdbc.time_zone=UTC（避免时区干扰）

为什么 setTimestamp() 写入 Oracle DATE 字段后时间部分丢了？

用 PreparedStatement.setTimestamp(1, ts) 往 Oracle DATE 列写入 LocalDateTime.now() 转成的 Timestamp，结果数据库里只剩日期，时间全为 00:00:00。

Oracle DATE 类型本身支持时分秒，问题出在 JDBC 驱动的写入策略：它看到目标列是 DATE，就主动把 Timestamp 的毫秒和纳秒部分清零，并可能进一步舍入——但更大概率是驱动用了过时的 setDate() 逻辑回退。

绕过方式：改用 setObject(1, localDateTime, JDBCType.TIMESTAMP)，强制走 TIMESTAMP 路径
或者，建表时直接把字段类型改成 TIMESTAMP（推荐），Oracle 对 TIMESTAMP 的 JDBC 支持更干净
避免用 setDate() 或 setObject(..., java.sql.Date.class)，这两者必然丢时间

Oracle 时区 + Java LocalDateTime 导致时间偏移 8 小时？

LocalDateTime 没有时区概念，但 Oracle TIMESTAMP WITH TIME ZONE 或会话时区（ALTER SESSION SET TIME_ZONE = 'Asia/Shanghai'）会影响 JDBC 读写行为。

典型现象：Java 本地存的是 2024-05-20T14:30:45，入库后查出来变成 2024-05-20T06:30:45（差 8 小时）——其实是驱动把 LocalDateTime 当作 JVM 默认时区时间，转成 UTC 写入，再按会话时区读出。

最稳做法：统一用 TIMESTAMP（无时区）类型 + LocalDateTime，禁用带时区的 Oracle 类型
如果必须用 TIMESTAMP WITH TIME ZONE，Java 端改用 ZonedDateTime 或 OffsetDateTime，别碰 LocalDateTime
检查 Oracle 会话时区：SELECT SESSIONTIMEZONE FROM DUAL，确保和应用部署环境一致

真正麻烦的从来不是类型名对不上，而是驱动在背后悄悄做时区转换、精度截断、类型降级——这些动作不会报错，只默默改掉你的数据。盯住 getTimestamp() 和 setObject(..., JDBCType.TIMESTAMP) 这两个点，基本能避开八成坑。