Java 时区设计 - ZonedDateTime 与 Instant 的选择

java.time API 概览

Java 8 以 JSR-310 的形式引入了 java.time 包，由 Stephen Colebourne(Joda-Time 的创建者)设计。该包围绕五个核心类构建：Instant、OffsetDateTime、ZonedDateTime、LocalDateTime 和 LocalDate。每个类表示关于某一时刻的不同信息层级，选择正确的类是正确处理时区的基础。

选择规则是使用所需最少信息量的类。当不涉及时区时使用 LocalDate 或 LocalDateTime；当 UTC 偏移量足够时使用 OffsetDateTime；当需要遵循未来夏令时变化的 IANA 时区语义时使用 ZonedDateTime；当只关心绝对时刻时使用 Instant。选择最不复杂但能满足需求的类型，可以防止信息意外丢失并简化推理。

Instant - 无时区的机器时间

Instant 将绝对时刻表示为从 Unix 纪元(1970-01-01T00:00:00Z)起的纳秒数。它不携带任何时区信息，代表地球上任何地方的同一时刻。日志时间戳、事件创建时间和 API 响应时间通常应该使用 Instant，因为它们的含义不依赖于任何本地时区。

对 Instant 的算术运算简单且可预测。plus(Duration.ofHours(1)) 始终精确地推进一个物理小时，不受任何夏令时转换的影响。代价是 Instant 无法直接回答“现在东京是几号？”这样的问题，必须先与 ZoneId 结合。转换只在展示层发生，而这正是它应该在的位置。

ZonedDateTime - 完整的时区感知

ZonedDateTime 将 LocalDateTime 与 ZoneId(如 Asia/Tokyo)组合在一起。它携带 IANA 时区名称，因此能够跟踪未来的夏令时变化和历史时区更新。对于夏令时转换期间出现的模糊挂钟时间，ZonedDateTime 提供了 withEarlierOffsetAtOverlap() 和 withLaterOffsetAtOverlap() 来明确选择。

ZonedDateTime 的算术运算会随着所加单位切换基准时间线。官方 javadoc 将 plusHours 这类时间单位的加法定义为 instant 时间线上的运算：加 1 小时始终等于物理时间上的 1 小时之后，其副作用是本地日期时间(挂钟)可能移动 1 小时以外的量。跨越夏令时“春进”边界正是这种情况，挂钟看上去会一下跳过两个小时。相对地，plusDays 这类日期单位的加法运行在本地时间线上，保持挂钟时刻不变而推进日期，也就是人类对“明天的同一时间”的直觉。正如 javadoc 所写，加 1 天并不等于加 24 小时：物理上经过的时间可能是 23 小时或 25 小时。想推进物理时间就用 plusHours 或 Duration，想保持挂钟就用 plusDays 或 Period。当算术运算至关重要时，务必包含夏令时边界测试。

OffsetDateTime - 当偏移量就够用时

OffsetDateTime 与 ZonedDateTime 类似，但它只存储 UTC 偏移量(如 +09:00)，而不是完整的 IANA 时区。由于偏移量锁定了 UTC 时间，时刻是明确的，但它不跟踪未来的夏令时策略变更。这使其成为 ISO 8601 和 RFC 3339 等序列化格式的理想选择，其中本地时间和 UTC 偏移量均被逐字表达。

PostgreSQL 的 TIMESTAMP WITH TIME ZONE 列在内部以 UTC 存储值，JDBC 驱动程序通常将其映射为 OffsetDateTime 或 Instant。持久化 OffsetDateTime 可以保留原始偏移量以供审计，同时仍允许明确地转换为 UTC。使用 ZonedDateTime 存储数据有风险 - 如果国家日后追溯性地更改其夏令时政策，可能导致重新解读。

Spring Boot 与 JPA 集成

Spring Boot 3.x 和 Hibernate 6 直接支持 Instant 和 OffsetDateTime 作为实体字段类型。使用 java.util.Date 或 Calendar 的遗留代码应该迁移，列类型的选择应与之匹配：TIMESTAMP 用于无时区的本地时间，TIMESTAMPTZ(PostgreSQL)或 TIMESTAMP(MySQL 配置了 serverTimezone)用于绝对时间。你在实体层选择的映射方式直接决定了时区 Bug 是否可能发生。

Jackson 的 JSON 序列化同样需要留意。在仅注册了 JavaTimeModule 的原生 Jackson 配置下，Instant 会被输出为数字纪元秒，这对期望 ISO 8601 字符串的 API 消费者来说是意外之举。与其依赖框架的默认值，不如用 spring.jackson.serialization.write-dates-as-timestamps=false 这样的显式设置把输出固定为 ISO 8601，这是现代标准，也是 Day.js 和 Luxon 等 JavaScript 库所期望的格式。在整个技术栈中统一序列化约定可以避免无数互操作 Bug。

类选择的决策流程

从这个问题开始：“这里需要人类地理的概念吗？”如果答案是否(日志、事件、机器时间戳)，使用 Instant。如果是，则问该值是否必须跟踪未来的时区规则变化。对于用户安排的未来事件(如闹钟),ZonedDateTime 是正确的选择。对于历史记录和已完成的交易，OffsetDateTime 更安全，因为其含义在写入时就被冻结了。对于没有任何时间分量的纯日期，LocalDate 是正确答案。

一个应用程序使用 java.time 中的多种类型是正常且健康的。强制将所有内容都放入 ZonedDateTime 会给日志增加不必要的信息并使序列化复杂化。在边界层(DTO、数据库列、API 契约)记录每个字段使用哪种类型，90% 的时区 Bug 就会自然消失。剩余的 10% 通常与夏令时边界处的测试覆盖率有关，适当的单元测试可以及早发现。