Java ZoneRules 怎么处理夏令时重复时间：偏移选择、间隔判断与回放验收

跨地区预约最容易在夏令时切换夜里出错：同一个 LocalDateTime 可能对应两个真实瞬间，也可能根本不存在。Java 里不要直接把本地时间拼成字符串再猜偏移，先交给 ZoneRules 判断有效偏移，再决定拒绝、取前一个还是明确选择后一个。

先看 ZoneRules 返回了什么

ZoneRules#getValidOffsets(LocalDateTime) 是判断入口。正常时间返回一个偏移；回拨重叠时返回两个偏移；跳时缺口返回空列表。这个返回值比直接调用 atZone 更适合作为预约入库前的业务门禁。

ZoneId zone = ZoneId.of("Europe/Berlin");
ZoneRules rules = zone.getRules();
LocalDateTime local = LocalDateTime.of(2026, 10, 25, 2, 30);

List offsets = rules.getValidOffsets(local);
switch (offsets.size()) {
    case 1 -> System.out.println("正常: " + offsets.get(0));
    case 2 -> System.out.println("重复: " + offsets);
    case 0 -> System.out.println("缺失: " + rules.getTransition(local));
    default -> throw new IllegalStateException("unexpected offsets");
}

同一份代码还应该记录 zone、原始本地时间和返回的偏移列表。只记录“转换成功”会把重复时间的选择悄悄吞掉，后面无法解释为什么订单差了一小时。

重复小时：不要让默认偏移替业务做决定

欧洲中部时间回拨时，02:30 会出现两次：一次带 +02:00，一次带 +01:00。如果业务约定“沿用夏令时偏移”，可以取列表第一个；如果约定“取回拨后的标准时间”，可以取第二个。关键是策略要显式。

static ZonedDateTime resolveOverlap(LocalDateTime local, ZoneId zone,
                                    boolean preferLaterOffset) {
    ZoneRules rules = zone.getRules();
    List offsets = rules.getValidOffsets(local);
    if (offsets.size() == 1) return ZonedDateTime.ofLocal(local, zone, offsets.get(0));
    if (offsets.size() == 2) {
        ZoneOffset chosen = preferLaterOffset ? offsets.get(1) : offsets.get(0);
        return ZonedDateTime.ofLocal(local, zone, chosen);
    }
    throw new DateTimeException("local time is in a gap: " + local);
}

这里的 preferLaterOffset 不是“时间更晚”的模糊说法，而是选择偏移列表中的第二个规则结果。入库前最好把选择原因写入审计字段，例如 DST_OVERLAP_STANDARD_OFFSET。

缺失时间：自动推过去可能改变用户输入

春季跳时会产生一段不存在的本地时间。getValidOffsets 返回空列表时，可以通过 getTransition 拿到缺口的前后边界，但是否推到缺口之后，应该由产品规则决定。会议预约通常提示用户重选；批处理导入才可能允许推到转换后的时间。

ZoneOffsetTransition transition = rules.getTransition(local);
if (transition != null && transition.isGap()) {
    Duration gap = transition.getDuration();
    throw new DateTimeException("missing local time, gap=" + gap);
}

用瞬间回放测试锁住边界

不要只测一个“能转成功”的日期。测试至少覆盖正常点、重复区间前后、缺口前后，并断言最终 Instant。这样即使时区规则库升级，业务也能在回归阶段看到差异。

@Test
void overlapMustKeepSelectedOffset() {
    ZoneId zone = ZoneId.of("Europe/Berlin");
    LocalDateTime local = LocalDateTime.of(2026, 10, 25, 2, 30);
    ZonedDateTime standard = resolveOverlap(local, zone, true);
    assertEquals(ZoneOffset.of("+01:00"), standard.getOffset());
    assertEquals(local, standard.toLocalDateTime());
}

常见问题

为什么不直接调用 LocalDateTime.atZone？

它会按默认规则处理缺口或重叠，适合展示，不适合在需要可审计选择的业务入口里代替策略判断。

保存 ZonedDateTime 就够了吗？

业务记录建议同时保存原始本地时间、ZoneId、最终偏移和 Instant，才能复现用户输入与系统决策。

时区规则变化会影响历史订单吗？

历史订单应以已保存的 Instant 为准；重新展示时再使用 ZoneId 转换，不要用今天的规则重新猜测旧的本地时间。

验收清单

• 正常时间、重复时间、缺失时间分别有测试。
• 重复时间的偏移选择有明确业务名和日志。
• 最终持久化值包含 Instant，而非只有本地字符串。
• 时区 ID 来自受控配置，不接受任意用户输入直接进入核心账务逻辑。