如何在Java中映射Oracle的DATE与TIMESTAMP类型_java.sql.Timestamp与时区处理-Oracle-PHP中文网

Oracle DATE映射为java.sql.Date（仅年月日），TIMESTAMP映射为java.sql.Timestamp（含纳秒），二者均无时区信息且默认按JVM本地时区解析；正确做法是显式传入Calendar指定时区，或对TIMESTAMPTZ使用oracle.sql.TIMESTAMPTZ.toTimestamp(TimeZone)转换。

Oracle DATE 和 TIMESTAMP 在 JDBC 中默认映射成什么

java 用 java.sql.date、java.sql.time、java.sql.timestamp 接 oracle 字段时，jdbc 驱动（比如 ojdbc8）会按字段类型自动选择映射目标：date 映射为 java.sql.date（只含年月日），timestamp 映射为 java.sql.timestamp（含秒和纳秒）。但关键问题是：它们都**不带时区信息**，且默认按 jvm 本地时区解释。

常见错误现象：TIMESTAMP 存的是 2024-05-20 14:30:00.123（UTC+8），查出来却变成 2024-05-20 14:30:00.123（被当成 JVM 本地时间再转 UTC 存进 Timestamp 对象），导致跨时区应用读写错乱。

Oracle DATE 类型本身无时区，精度到秒；TIMESTAMP 也无时区，除非显式声明为 TIMESTAMP WITH TIME ZONE
ojdbc 默认把 TIMESTAMP 当作“本地时间戳”处理，不保存原始时区上下文
如果数据库服务器、应用服务器、JVM 时区不一致，getTimestamp() 返回值可能偏移 1 小时甚至更多

怎么让 ResultSet.getTimestamp() 按指定时区解析

必须显式传入 Calendar 实例，否则 JDBC 使用 JVM 默认时区。这不是可选优化，是纠正行为的必要步骤。

使用场景：你明确知道 Oracle 字段存的是 UTC 时间，或统一用东八区时间存储，但 JVM 运行在 UTC 环境下。

Calendar utc = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
Timestamp ts = rs.getTimestamp("created_at", utc);

rs.getTimestamp(String, Calendar) 是唯一可靠方式，rs.getTimestamp(String) 必须避免
Calendar 的时区必须与字段实际存储逻辑一致——不是数据库服务器时区，而是业务约定的“语义时区”
别用 TimeZone.getDefault() 初始化 Calendar，它随 JVM 启动固化，改系统时区不生效
Spring JdbcTemplate 可通过 setResultSetExtractor 统一封装该逻辑，避免每处手写

Oracle TIMESTAMP WITH TIME ZONE 怎么对应 Java 类型

Oracle 原生支持带时区的时间戳，但 JDBC 标准没定义直接映射类型。ojdbc 把 TIMESTAMP WITH TIME ZONE 映射为 oracle.sql.TIMESTAMPTZ，这是 Oracle 私有类，不能直接当 java.time.Instant 或 ZonedDateTime 用。

常见错误现象：直接 rs.getObject("ts_tz", ZonedDateTime.class) 抛 SQLFeatureNotSupportedException；或强转 oracle.sql.TIMESTAMPTZ 后调 toJdbc() 又丢时区。

正确做法是先取 oracle.sql.TIMESTAMPTZ，再调 toTimestamp(TimeZone) 转成带明确时区语义的 Timestamp
或者用 toJDBCDate()/toJDBCTime() 辅助提取，但推荐走标准 JDBC 流程：用 getString() 读 ISO 格式字符串，再用 OffsetDateTime.parse() 解析
注意：oracle.sql.TIMESTAMPTZ.toString() 输出格式依赖 NLS 设置，不可靠；getString() 更稳定
若用 MyBatis，需自定义 TypeHandler 处理 TIMESTAMPTZ → OffsetDateTime，不能依赖默认映射

java.time API 怎么安全接入现有 JDBC 代码

别强行把 LocalDateTime 塞进 PreparedStatement.setObject()——ojdbc 8+ 虽支持，但行为取决于字段类型和驱动版本，容易踩兼容性坑。

使用场景：新代码想用 Instant 或 ZonedDateTime，但数据库仍是 DATE 或 TIMESTAMP（无时区）。

写入：统一转成 Timestamp.from(instant)，确保 instant 是你要存的绝对时间点（如 UTC）
读取：用 rs.getTimestamp(col, utcCal) 得到 Timestamp，再调 timestamp.toInstant() —— 它等价于 instant = timestamp.getTime() + offset，其中 offset 是传入的 Calendar 时区偏移
别依赖 Timestamp.toInstant() 的默认行为，它内部用 System.getDefaultTimeZone()，不可控
如果字段语义是“某个时区的本地时间”（比如“北京时间下午两点”），就该用 ZonedDateTime.of(LocalDateTime, ZoneId) 构造，再转 Instant 写入