在 hibernate 5 中，仅靠 `hibernate.jdbc.time_zone=utc` 无法保证 `localdatetime` 字段读取时保持 utc 语义；需改用 `offsetdatetime` 或 `instant` 等时区感知类型，并配合数据库列类型（如 `timestamp with time zone`）与 jdbc 驱动协同工作。
Hibernate 5 对时间处理的设计哲学是「数据库时区对齐优先，而非应用层时区抽象」。hibernate.jdbc.time_zone 的本质作用并非为业务时间建模服务，而是解决 JDBC 驱动在无时区上下文（如 TIMESTAMP 列）下默认按 JVM 时区解析时间导致的数据错位问题。例如：当数据库中存储的是 2024-01-01 00:00:00（本意为 UTC），而 JVM 时区为 Asia/Shanghai（UTC+8），不配置该属性时，rs.getTimestamp("created_at") 会将其解释为「北京时间 00:00」，再转为 Timestamp 对象后内部毫秒值实际对应 UTC 时间 2023-12-31 16:00:00 —— 这就是你观察到的“读取后变成默认时区”的根本原因。
但关键在于：LocalDateTime 本身不携带时区信息，它只是一个“本地日历时间快照”。Hibernate 将其映射到数据库 TIMESTAMP 类型时，完全丢失了原始时区上下文；即使写入时通过 Calendar.getInstance(UTC) 强制按 UTC 解析，读取时仍需依赖同样的 Calendar 实例还原 —— 而 Timestamp 构造器 new Timestamp(c.getTimeInMillis()) 会无视 Calendar 的时区，仅使用其毫秒值，并在 toString() 等操作中按 JVM 默认时区格式化，造成认知偏差。
✅ 正确解法（推荐）：升级时间类型语义
使用 JSR-310 时区感知类型替代 LocalDateTime，并确保数据库列支持时区：
@Entity
public class Event {
@Id
private Long id;
// ✅ 推荐：明确表达“带偏移的时间点”，JDBC 4.2+ 驱动可直连 TIMESTAMP WITH TIME ZONE
@Column(columnDefinition = "TIMESTAMP WITH TIME ZONE")
private OffsetDateTime occurredAt;
// ✅ 或更简洁：仅关注绝对时间点（无时区歧义）
@Column(columnDefinition = "TIMESTAMP WITH TIME ZONE")
private Instant createdAt;
}对应数据库 DDL（PostgreSQL 示例）：
CREATE TABLE event ( id BIGSERIAL PRIMARY KEY, occurred_at TIMESTAMPTZ, -- 注意：不是 TIMESTAMP！ created_at TIMESTAMPTZ );
此时，Hibernate 5 会自动调用 ResultSet.getObject("occurred_at", OffsetDateTime.class)，绕过 Calendar 和 Timestamp 的中间转换，直接获得带 UTC 偏移（如 2024-01-01T00:00Z）的实例，彻底规避时区误解析。
⚠️ 注意事项：
- 不要混用 LocalDateTime + hibernate.jdbc.time_zone 试图“模拟 UTC”——这属于反模式，逻辑脆弱且不可测试；
- 若受限于历史表结构（只能用 TIMESTAMP 无时区列），则必须自定义 UserType（如继承 org.hibernate.usertype.UserType），在 nullSafeGet() 中显式用 Calendar.getInstance(ZoneId.of("UTC").toTimeZone()) 提取，并手动构造 LocalDateTime（但强烈不推荐，易出错）；
- ZonedDateTime 在 Hibernate 5 中支持有限，优先选用 OffsetDateTime 或 Instant；
- Spring Boot 2.3+ 默认启用 spring.jpa.properties.hibernate.jdbc.time_zone=UTC，但仅对写入生效，读取行为仍取决于 Java 类型选择。
总结：Hibernate 5 的时间处理是“数据库驱动型”而非“应用驱动型”。要真正实现端到端 UTC 一致性，必须让数据模型、数据库列类型、Java 类型、JDBC 驱动四者统一在时区感知语义下。放弃 LocalDateTime，拥抱 Instant 或 OffsetDateTime，是最简洁、可靠、符合现代 Java 时间 API 设计原则的方案。
