LocalDateTime 遇到夏令时：缺口、重叠与预约确认

2025-03-30 02:30符合年月日时分格式，也能被STRICT解析成LocalDateTime；放到Europe/Berlin，它却落在春季时钟前跳的缺口中。日期合法，与这个地区真的存在这一个钟点，是两层判断。

秋季还有反方向的问题：同一个02:30出现两次。没有额外偏移信息，本地时间不能唯一确定Instant。给解析器加STRICT不会自动替产品选择前一次还是后一次。

先把排期政策写成三个分支：没有合法偏移就拒绝；只有一个就使用它；有多个而调用者没有选择，就要求补充。若调用者提供了偏移，还要验证它确实属于这个时区与本地时间的组合。

import java.time.*;
import java.time.format.*;
import java.util.*;
public class LocalSchedule {
    static final DateTimeFormatter FORMAT = DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm", Locale.ROOT)
            .withResolverStyle(ResolverStyle.STRICT);
    static Instant resolve(LocalDateTime local, ZoneId zone, ZoneOffset selected) {
        List<ZoneOffset> valid = zone.getRules().getValidOffsets(local);
        if (valid.isEmpty()) throw new DateTimeException("GAP");
        if (valid.size() > 1 && selected == null) throw new DateTimeException("OFFSET_REQUIRED");
        ZoneOffset chosen = selected == null ? valid.get(0) : selected;
        if (!valid.contains(chosen)) throw new DateTimeException("INVALID_OFFSET");
        return ZonedDateTime.ofStrict(local, chosen, zone).toInstant();
    }
    public static void main(String[] args) {
        ZoneId zone = ZoneId.of("Europe/Berlin");
        LocalDateTime gap = LocalDateTime.parse("2025-03-30 02:30", FORMAT);
        System.out.println("local_parse=" + gap);
        try { resolve(gap, zone, null); throw new AssertionError(); }
        catch (DateTimeException expected) { System.out.println("spring=" + expected.getMessage()); }
        LocalDateTime overlap = LocalDateTime.parse("2025-10-26 02:30", FORMAT);
        try { resolve(overlap, zone, null); throw new AssertionError(); }
        catch (DateTimeException expected) { System.out.println("autumn=" + expected.getMessage()); }
        System.out.println("earlier=" + resolve(overlap, zone, ZoneOffset.ofHours(2)));
        System.out.println("later=" + resolve(overlap, zone, ZoneOffset.ofHours(1)));
        try { resolve(overlap, zone, ZoneOffset.ofHours(3)); throw new AssertionError(); }
        catch (DateTimeException expected) { System.out.println("wrong=" + expected.getMessage()); }
    }
}

在JDK 17保存为 LocalSchedule.java，执行 java LocalSchedule.java。样本采用明确的柏林2025历史切换日期，不依赖当前服务器默认时区。

local_parse=2025-03-30T02:30
spring=GAP
autumn=OFFSET_REQUIRED
earlier=2025-10-26T00:30:00Z
later=2025-10-26T01:30:00Z
wrong=INVALID_OFFSET

本地日期时间缺少哪些信息

LocalDateTime保存日历与钟点，不包含区域时区，也不是一条UTC时间轴坐标。它能准确表示用户输入的02:30，却不能在不知道地区规则时判定这次输入对应哪个瞬间。

ZoneRules.getValidOffsets为这份映射提供检查入口。正常钟点通常有一个合法偏移，缺口为零，重叠通常为两个。程序对多个偏移采用显式选择，而不把列表第一个当产品默认值；未来规则或业务政策变化时，这份决定仍然可见。

ZonedDateTime.ofStrict最后再核对三者组合。它不是前面检查的替代品，而是用明确偏移构造结果的校验入口。若只调用atZone，JDK可以采用其默认的缺口与重叠处理方式，那是库提供的政策，不一定等于业务要求。

两个合法偏移，确实差了一个小时

重叠样本选+02:00得到00:30Z，选+01:00得到01:30Z。界面都可以显示当地02:30，因此审计或回显时不能只展示LocalDateTime。至少要保留ZoneId及选择的偏移或最终Instant，才能解释究竟排在哪一次。

本例拒绝缺口，而不是自动推迟。预约系统也可能选择向后调整、提示用户重新选择或取消当天执行，每种政策都合理，但应得到明确确认。自动改时刻会影响用户预期，不应藏在一个通用转换方法里。

若偏移由客户端提交，也不能直接信任。例如柏林冬季时间配+03:00不是这组规则允许的组合，程序应拒绝而不是用偏移优先解释，再顺手覆盖区域时区。只保存offset会失去未来政策信息，只保存ZoneId又可能缺少重叠选择，模型应按用途保留必要字段。

预约页面可以先给候选，再确认具体一次

对于提醒或预约界面，可以把“输入当地02:30”与“确认执行瞬间”分成两步。第一次请求返回合法候选，正常时刻一项、缺口零项、重叠两项。重叠时将偏移和可解释的日期一起展示，让用户选择，不能在两个同样写着02:30的按钮后面藏不同瞬间。

下面的 ScheduleConfirmation.java 展示这项协议。它不模拟真实存储，Confirmed只是准备交给持久化层的一份明确结果。确认时重新检查区域规则及预览瞬间，避免调用方把一份旧选项或自相矛盾的offset/Instant组合直接保存。

import java.time.*;
import java.util.*;
public class ScheduleConfirmation {
    record Option(ZoneOffset offset, Instant instant) {}
    record Confirmed(LocalDateTime local, ZoneId zone, ZoneOffset offset, Instant instant) {}
    static List<Option> options(LocalDateTime local, ZoneId zone) {
        return zone.getRules().getValidOffsets(local).stream()
                .map(offset -> new Option(offset,ZonedDateTime.ofStrict(local,offset,zone).toInstant()))
                .sorted(Comparator.comparing(Option::instant)).toList();
    }
    static Confirmed confirm(LocalDateTime local, ZoneId zone, ZoneOffset selected, Instant preview) {
        List<Option> current = options(local,zone);
        Option chosen = current.stream().filter(o -> o.offset().equals(selected)).findFirst()
                .orElseThrow(() -> new DateTimeException("selection no longer valid"));
        if (!chosen.instant().equals(preview)) throw new DateTimeException("preview differs from confirmed instant");
        return new Confirmed(local,zone,selected,chosen.instant());
    }
    public static void main(String[] args) {
        ZoneId zone = ZoneId.of("Europe/Berlin");
        LocalDateTime repeated = LocalDateTime.of(2025,10,26,2,30);
        List<Option> choices = options(repeated,zone);
        System.out.println("options=" + choices.size() + ", distance_seconds="
                + Duration.between(choices.get(0).instant(),choices.get(1).instant()).getSeconds());
        Confirmed stored = confirm(repeated,zone,choices.get(0).offset(),choices.get(0).instant());
        System.out.println("confirmed=" + stored.instant());
        System.out.println("display=" + stored.instant().atZone(stored.zone()));
        System.out.println("normal-options=" + options(LocalDateTime.of(2025,2,1,2,30),zone).size());
        System.out.println("gap-options=" + options(LocalDateTime.of(2025,3,30,2,30),zone).size());
        try { confirm(repeated,zone,choices.get(0).offset(),choices.get(1).instant()); }
        catch (DateTimeException expected) { System.out.println("stale-or-tampered=REJECTED"); }
        if (!stored.instant().atZone(zone).toLocalDateTime().equals(repeated)) throw new AssertionError("display drift");
    }
}

options=2, distance_seconds=3600
confirmed=2025-10-26T00:30:00Z
display=2025-10-26T02:30+02:00[Europe/Berlin]
normal-options=1
gap-options=0
stale-or-tampered=REJECTED

两个候选相差3600秒，回显选中的Instant时，又能恢复所选当地钟点和偏移。篡改示例把前一个偏移与后一个瞬间拼在一起，确认入口拒绝。这不是要求客户端必须提交Instant，而是演示：如果接口允许同时提交多种时间表示，就要核对它们一致，不能随便挑一个字段覆盖其他字段。

一次确认后，执行队列可以按Instant判断是否到期，审计仍保留原当地时间、ZoneId和偏移，用来解释用户当时选择了什么。不要在每次展示时用服务器默认时区改写语义；也不要仅凭“提前一小时”这样的相对文字记录重叠选择，回看时会丢掉判断依据。

预览与确认之间区域规则可能更新，长时间停留的页面也可能携带旧选项，因此服务端确认时仍应重算或核对规则版本。这个实验使用JDK自带规则处理明确历史日期，没有捏造发生过一次实际规则变更；真实未来排期应按部署策略记录所用规则与重新解释政策。

重复预约另有幂等要求。同一份当地时间在重叠日可以合法选择两个不同瞬间，不能只用local字符串当唯一请求标识来合并；反过来，重试同一个已确认请求也不应生成两份提醒。应使用独立请求标识，并比较已确认的时间语义，格式解析成功本身不解决重复提交。

长期排期要决定何时解释规则

一次立即执行的请求，可以在接收时计算Instant并确认。长期重复排期则常常需要保存当地规则，例如每天02:30与地区；时区政策更新以后，是跟随新政策重新解释，还是保留之前算好的瞬间，需要业务作出决定。

数据库和消息里若仅有一段 2025-10-26T02:30 文本，下游不能可靠补出缺失选择。服务器部署地区也不应该成为隐式默认值。不同入口应复用同一政策，或明确区分“绝对时刻输入”和“本地排期输入”。

测试用正常时刻、春季缺口、秋季两种偏移和错误偏移分别覆盖。不要只验证parse成功，真正需要断言的是最终Instant与拒绝原因。格式解析是一道门，时区映射是另一道门，两道都通过，排期才算拥有唯一而可解释的执行时刻。