ResultSet.getObject("col", OffsetDateTime.class)是唯一推荐的读取方式，因Oracle TIMESTAMP WITH TIME ZONE字段默认不保留时区信息，其他方式如getTimestamp()或getObject()无类型参数会导致偏移丢失、跨环境时间错乱。
ResultSet.getObject("col", OffsetDateTime.class) 是唯一推荐的读取方式
Oracle 的 TIMESTAMP WITH TIME ZONE 字段在 JDBC 中**默认不保留时区信息**，rs.getObject("col") 或 rs.getTimestamp("col") 返回的 java.sql.Timestamp 会丢掉偏移量，且值按 JVM 本地时区反向解释——这导致跨环境（如测试用 Asia/Shanghai、生产用 UTC）查出时间差 1 小时甚至夏令时错乱。
必须显式指定类型：
-
rs.getObject("col", OffsetDateTime.class)—— JDBC 4.2+ 标准做法，能完整还原数据库中存储的+08:00或-05:00偏移 - 避免
rs.getObject("col", LocalDateTime.class)：看似不报错，实则把带偏移的时间强行按 JVM 时区“解释”成无时区时间，值已漂移 - 不用
rs.getString("col")再解析：格式依赖 Oracle NLS 设置，TO_CHAR(ts, 'YYYY-MM-DD HH24:MI:SS TZR')输出可能为US/Pacific或-07:00，手动解析极易出错且丢失纳秒精度
写入时必须用 setObject(idx, offsetDateTime, JDBCType.TIMESTAMP_WITH_TIMEZONE)
直接 ps.setObject(1, odt) 可能触发 ORA-01805 错误，不是格式问题，而是驱动无法将 OffsetDateTime 的偏移映射到 Oracle 认可的时区上下文。
关键动作是显式声明 SQL 类型：
立即学习“Java免费学习笔记（深入）”；
- 用
ps.setObject(1, odt, JDBCType.TIMESTAMP_WITH_TIMEZONE)—— 告诉驱动：“这个值要按带时区语义写入”，驱动才会正确处理偏移 - 确保连接 URL 含
?oracle.jdbc.timezoneAsRegion=false：否则驱动会把+08:00强行转成Asia/Shanghai，而后者在不同 JVM 上可能对应不同偏移（夏令时切换时变成+09:00） - 别传
ZonedDateTime：虽然某些驱动能接受，但 JDBC 规范只保证OffsetDateTime行为一致；ZonedDateTime带时区规则（如 DST），Oracle 不需要也不理解
MyBatis / Spring Data JPA 必须绕过默认映射
这些框架默认把 TIMESTAMP WITH TIME ZONE 当作普通 TIMESTAMP 处理，getObject() 调用被拦截，最终仍走 getTimestamp() 路径。
实操要点：
- MyBatis：写自定义
TypeHandler<OffsetDateTime>，在getResult(ResultSet rs, String col)里调用rs.getObject(col, OffsetDateTime.class)；XML 映射中用jdbcType="OTHER"防止自动降级 - Spring Data JPA：实体字段加
@Column(columnDefinition = "TIMESTAMP WITH TIME ZONE")，并配@Convert(converter = OffsetDateTimeConverter.class)；OffsetDateTimeConverter的convertToEntityAttribute直接返回输入值，convertToDatabaseColumn调用setObject(..., JDBCType.TIMESTAMP_WITH_TIMEZONE) - JdbcTemplate：别用
BeanPropertyRowMapper，它对OffsetDateTime字段仍调getTimestamp()；改用new ColumnMapper<YourPojo>() { public YourPojo mapRow(ResultSet rs) { odt = rs.getObject("col", OffsetDateTime.class); } }
oracle.sql.TIMESTAMPTZ 只在特殊场景下才用
oracle.sql.TIMESTAMPTZ 是 Oracle 驱动私有类，能读取原始时区名称（如 America/Los_Angeles），但代价极高。
仅当以下条件同时满足时才考虑：
- 业务强依赖时区地区名（而非偏移），比如要区分
PST和PDT（同一地区不同时段） - 你控制所有运行环境，且能保证 Oracle 驱动版本统一（
ojdbc8+）、JVM 时区配置一致 - 测试能 mock
oracle.sql.TIMESTAMPTZ（实际很难，它依赖 native driver logic）
绝大多数业务只需要知道“这个时间点相对于 UTC 是 +08:00”，OffsetDateTime 更轻量、标准、可测。硬用 TIMESTAMPTZ 只会让代码绑定 Oracle、增加维护成本。
真正容易被忽略的是：即使驱动参数设对、Java 类型选对，如果连接池（如 HikariCP）没把 oracle.jdbc.timezoneAsRegion=false 透传给底层 Connection，整个链路还是失效。检查方式：打印 connection.getMetaData().getURL() 确认参数存在。
