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()—— 它能完整读出 OracleDATE里的时分秒 - 如果必须用
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"/> - 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。
立即学习“Java免费学习笔记（深入）”；
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) 这两个点，基本能避开八成坑。
