OffsetDateTime跨夏令时时区偏移未重算：两种实例化结果不一致咨询

这个问题我之前也踩过坑，本质是没搞清楚OffsetDateTime的核心设计逻辑：它只是LocalDateTime和固定ZoneOffset的组合，并不绑定ZoneId，完全不知道时区规则（比如夏令时切换）的存在。

咱们来拆解你遇到的场景：

1. 当你调用OffsetDateTime.now().plusMonths(1)时：
   • now()会根据系统时区的ZoneId拿到当前的OffsetDateTime（比如中欧时区10月中旬，此时是夏令时，偏移量+02:00）；
   • plusMonths(1)只负责把LocalDateTime部分加1个月，原有的ZoneOffset会被直接保留——它根本不会去查“1个月后的这个时区是不是已经切换到冬令时了”，所以得到的11月15日的OffsetDateTime，偏移量还是+02:00。
2. 而OffsetDateTime.ofInstant(inAMonth.toInstant(), ZoneId.systemDefault())的逻辑完全不同：
   • 先把inAMonth转成Instant（这是与时区无关的时间戳）；
   • 再根据指定的ZoneId，查询这个Instant对应的真实ZoneOffset（11月的中欧时区是冬令时，偏移量+01:00），然后生成新的OffsetDateTime。

这就导致两个对象的ZoneOffset不一样，自然用compareTo或者字段比对会不相等。

针对不能替换OffsetDateTime的解决方案 #

除了你提到的两种方式，我还推荐一种更灵活的写法——在流畅接口修改后，强制通过ZoneId重算偏移量：

ZoneId zone = ZoneId.systemDefault();
OffsetDateTime inAMonth = OffsetDateTime.now(zone)
    .plusMonths(1)
    .atZoneSameInstant(zone) // 用ZoneId重新计算当前Instant对应的正确偏移量
    .toOffsetDateTime();
OffsetDateTime inAMonth2 = OffsetDateTime.ofInstant(inAMonth.toInstant(), zone);
// 现在两个对象就会相等了

这个方法既保留了流畅接口的便利性，又能正确处理夏令时切换带来的偏移量变化。

内容的提问来源于stack exchange，提问作者rotzbouw