Oracle JDBC驱动默认用服务器时区硬解TIMESTAMP WITH TIME ZONE，导致偏移丢失；需设oracle.jdbc.timezoneAsRegion=false并显式调用rs.getObject("col", OffsetDateTime.class)，配合ojdbc8+及oracle.jdbc.javaTimeSupport=true方可保微秒与时区精度。
Oracle JDBC驱动默认按服务器时区硬解TIMESTAMP WITH TIME ZONE
这不是java或jvm的问题，而是oracle jdbc驱动（尤其是ojdbc8及更早版本）的默认行为：它把数据库返回的timestamp with time zone二进制值，直接用数据库所在操作系统的时区“硬解”成java.sql.timestamp——后者本身无时区字段，结果就是原始偏移信息彻底丢失。典型现象是：数据库存的是2024-05-20 14:00:00.123456 +09:00，但rs.gettimestamp("col")返回的却是2024-05-20 14:00:00.123（毫秒级），且隐含按服务器本地时区解释，跨环境部署时立刻出现8小时、11小时甚至夏令时偏差。
oracle.jdbc.timezoneAsRegion=true反而加剧时区歧义
很多文档推荐设oracle.jdbc.timezoneAsRegion=true，但它会让驱动把+08:00转成Asia/Shanghai再查JVM时区映射，而Asia/Shanghai在不同JVM上可能映射为+08:00或+09:00（夏令时生效时）。实际要的是原始偏移量，不是地区名。
-
oracle.jdbc.timezoneAsRegion=false才能暴露真实偏移（如+08:00），让Java层可控处理 - 该参数仅对
TIMESTAMP WITH TIME ZONE列生效，对普通TIMESTAMP列无效 - 必须搭配ojdbc8+（推荐ojdbc11），旧版驱动不识别此参数
ResultSet.getObject("col", OffsetDateTime.class)才是正确接收方式
rs.getTimestamp("col")和rs.getObject("col")默认都返回java.sql.Timestamp，等于主动丢弃时区。驱动即使配对了，也救不了这一层。
- 必须显式调用
rs.getObject("col", OffsetDateTime.class)，它能还原原始+08:00偏移 - 避免用
Calendar配合getTimestamp(int, Calendar)——Calendar.getInstance()依赖TimeZone.getDefault()，而Spring Boot等容器常覆盖它 - MyBatis需自定义
TypeHandler，否则@Select注解直出仍走默认Timestamp路径
微秒精度和时区必须同时保，否则精度会二次丢失
Oracle TIMESTAMP(6)存微秒，但JDBC默认截断到毫秒。更麻烦的是：如果字段是TIMESTAMP WITH TIME ZONE，而你用LocalDateTime接收，驱动会在转换时先按JVM时区做隐式偏移，再截断微秒——误差可能达毫秒级以上。
- 启用
oracle.jdbc.javaTimeSupport=true，否则OffsetDateTime.class会被降级 - 写入时用
ps.setObject(idx, offsetDateTime, JDBCType.TIMESTAMP_WITH_TIMEZONE)，别用setTimestamp() - 读取后若需转
Instant，用offsetDateTime.toInstant()，不要经由Timestamp中转
真正容易被忽略的点是：连接URL里的时区参数只影响驱动解析行为，不改变ResultSet的默认类型映射逻辑；哪怕URL全配对，只要代码里还调getTimestamp()，就等于前功尽弃。
立即学习“Java免费学习笔记（深入）”；
