ojdbc8从JDBC 4.2起引入oracle.jdbc.timezoneAsRegion参数但支持不完整，设为false时仍可能回退地区名映射；ojdbc11（JDBC 4.3）才严格按+08:00等偏移量暴露时区，且对OffsetDateTime.class兼容性更稳定。
ojdbc8 与 ojdbc11 对 oracle.jdbc.timezoneAsRegion 的支持差异
ojdbc8（对应 jdbc 4.2）开始引入 oracle.jdbc.timezoneasregion 参数，但仅在部分场景下生效；ojdbc11（jdbc 4.3）才完整支持该参数的解析与行为控制。关键区别在于：ojdbc8 中设为 false 后，驱动仍可能回退到地区名映射逻辑；ojdbc11 则严格按偏移量（如 +08:00）暴露时区信息，且对 resultset.getobject("col", offsetdatetime.class) 的兼容性更稳定。
用 getTimestamp(String, Calendar) 在不同驱动版本下的表现是否一致
不一致。ojdbc8 对 Calendar 传参的支持较弱，尤其当 Calendar 时区为 UTC 时，若数据库字段是 TIMESTAMP WITH TIME ZONE，ojdbc8 可能忽略 Calendar 并仍按 JVM 本地时区解析；ojdbc11 则会尊重 Calendar 时区，并尝试做一次“语义对齐”——但注意：这仍是模拟行为，不能替代原生时区类型。所以无论哪个版本，都应避免依赖此方式处理带时区字段。
为什么 ojdbc11 + timezoneAsRegion=false 仍可能拿到 Asia/Shanghai
常见原因有三个：
- 连接 URL 中该参数被其他配置覆盖（例如 HikariCP 的
dataSourceProperties未显式透传，或被ojdbc.properties文件中的同名配置覆盖） - Oracle 数据库端 NLS 参数设置了
NLS_TIME_TZ_FORMAT或NLS_TIME_FORMAT，导致驱动收到的是已格式化的字符串而非原始二进制时区信息 - 应用代码中调用了
ResultSet.getTimestamp("col")而非getObject("col", OffsetDateTime.class)—— 驱动再正确，Java 层丢弃时区的行为也救不回来
测试时如何验证驱动实际行为是否符合预期
最直接的方式是绕过 ORM，写一段裸 JDBC 查询并打印底层时区信息：
String sql = "SELECT CAST(SYSTIMESTAMP AS TIMESTAMP WITH TIME ZONE) FROM DUAL";
try (ResultSet rs = stmt.executeQuery(sql)) {
if (rs.next()) {
Object raw = rs.getObject(1);
System.out.println("Raw object class: " + raw.getClass().getName());
if (raw instanceof OffsetDateTime) {
System.out.println("Offset: " + ((OffsetDateTime) raw).getOffset());
}
}
}
同时检查日志中 JDBC 驱动加载的版本号（ojdbc11.jar 的 MANIFEST.MF 里有 Implementation-Version），避免因 classpath 混入旧版 jar 导致行为错乱。跨版本测试时，务必清空本地 Maven 仓库中的重复 jar，否则 ClassLoader 可能加载到意料之外的版本。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
