Oracle的TIMESTAMP WITH TIME ZONE在JDBC中对应java.time.OffsetDateTime（JDBC 4.2+推荐）或oracle.sql.TIMESTAMPTZ（Oracle专有类）；不能用java.sql.Timestamp接收，否则时区信息丢失并导致时间值错位。
Oracle的TIMESTAMP WITH TIME ZONE在JDBC里对应什么类型？
Java端不能直接用java.sql.Timestamp安全接收它——虽然能读出来，但时区信息会丢失，变成本地时区或UTC隐式转换，导致时间值错位。JDBC规范要求用java.time.OffsetDateTime（JDK 8+）或java.sql.Timestamp配合Calendar（已过时）。实际项目中应优先选OffsetDateTime，它天然保留偏移量，且与Oracle的TIMESTAMP WITH TIME ZONE语义对齐。
- 用
ResultSet.getObject("col", OffsetDateTime.class)读取，不是getTimestamp() - 写入时用
PreparedStatement.setObject(idx, offsetDateTime)，避免setTimestamp(idx, ts, cal) - 如果数据库列实际存的是带时区的
Asia/Shanghai等区域ID（而非+08:00），OffsetDateTime仍能正确解析偏移，但会丢失区域名称；需区域语义时得用ZonedDateTime并自行转换
为什么rs.getTimestamp("col")返回的时间总是不对？
这是最常见踩坑点：getTimestamp()底层会把数据库里的时区信息强行转成JVM默认时区再截断，比如数据库存的是2024-05-10 14:30:00.123 +09:00（东京），JVM时区是Asia/Shanghai（+08:00），它就变成2024-05-10 13:30:00.123，还丢掉了+09:00标记。更糟的是，不同JDBC驱动版本行为还不一致。
- Oracle JDBC driver 12.1+ 默认启用
oracle.jdbc.javaTimeSupport=true，此时getObject(..., OffsetDateTime.class)才可靠 - 旧驱动或未配参数时，
getObject可能回退到Timestamp，务必检查运行时实际返回类型 - 测试时别只看打印结果，用
offsetDateTime.getOffset()断言偏移量是否匹配数据库原始值
如何处理数据库里存的是Asia/Shanghai这种时区名的情况？
Oracle的TIMESTAMP WITH TIME ZONE支持两种格式：固定偏移（如+08:00）和区域ID（如Asia/Shanghai）。JDBC驱动读到后者时，OffsetDateTime只能拿到等效偏移（例如+08:00），原始区域名不可逆丢失。如果业务需要知道“用户当时在哪个时区”，就得换策略：
- 额外加一列存时区ID字符串（
VARCHAR2），和时间字段一起读写 - 读取后用
ZoneId.of("Asia/Shanghai").getRules().getOffset(instant)还原历史偏移（注意夏令时） - 写入前用
ZonedDateTime.withZoneSameInstant(ZoneId.of("Asia/Shanghai"))生成带区域的时间，再转OffsetDateTime传给JDBC（此时偏移按当前规则计算，不保证与原始存储完全一致）
Spring JdbcTemplate或MyBatis怎么适配？
框架本身不自动识别TIMESTAMP WITH TIME ZONE，得靠你显式指定类型。JdbcTemplate里要用BeanPropertyRowMapper的子类或自定义RowMapper，MyBatis则必须在resultMap里声明javaType="java.time.OffsetDateTime"。
立即学习“Java免费学习笔记（深入）”；
- JdbcTemplate示例：
new BeanPropertyRowMapper<MyEntity>(MyEntity.class) {{ // 覆盖默认映射 setColumnToPropertyOverrides(Map.of("created_at", "createdAt")); }};并在MyEntity中把字段声明为OffsetDateTime createdAt - MyBatis的
<result column="created_at" property="createdAt" javatype="java.time.OffsetDateTime"></result>必须写全，不能依赖类型推断 - HikariCP等连接池若启用了
leakDetectionThreshold，注意OffsetDateTime对象本身不重，但频繁创建可能触发GC压力，非关键路径可考虑复用DateTimeFormatter
TIMESTAMP WITH TIME ZONE真正麻烦的不是读写语法，而是时区语义在JDBC层被压缩成偏移量后，区域上下文、历史夏令时规则、用户意图这些信息全没了——一旦业务需要“还原用户提交时的本地时间”，光靠数据库字段根本不够。 
