LocalDateTime添加分钟在夏令时日期计算结果异常如何解决

LocalDateTime是不携带时区信息的日期时间类型，它自带的plusMinutes、plusHours这类方法只会对钟表显示的字面数值做加减，完全不会感知夏令时切换带来的时区偏移变化，直接用它做跨夏令时的时间累加必然会出现计算偏差。
你遇到的2021-10-31这个日期是欧洲部分时区夏令时结束的节点，当天凌晨2点会回拨1小时到1点，当日实际时长为25小时。你传入的待累加分钟数1440对应24个真实时长的小时，直接用LocalDateTime加1440分钟是按字面时间加24小时，没有扣除夏令时回拨的1小时，自然会得到2021-11-01 02:00:00.0的错误结果。

涉及时区、夏令时规则的时间计算，必须先将时间绑定到对应业务时区，转换为可感知时区规则的ZonedDateTime类型后再做时长累加，参考实现如下：

import java.sql.Timestamp;
import java.time.*;

public Timestamp addMinutes(long minutes, LocalDateTime recordDate, ZoneId bizZoneId) {
    // 将无时区的本地时间绑定到业务对应时区，获得可感知夏令时规则的时间对象
    ZonedDateTime zonedTime = recordDate.atZone(bizZoneId);
    // 按真实时间长度累加分钟数，自动处理夏令时切换的偏移调整
    ZonedDateTime calculatedTime = zonedTime.plus(Duration.ofMinutes(minutes));
    // 转换为Timestamp返回
    return Timestamp.from(calculatedTime.toInstant());
}

针对你举的测试场景，传入recordDate = LocalDateTime.parse("2021-10-31T02:00:00")、minutes=1440、bizZoneId = ZoneId.of("Europe/London")时，返回结果就是预期的2021-11-01 01:00:00.0。

• 调用上述方法时必须显式传入业务对应的时区ID，比如国内业务传ZoneId.of("Asia/Shanghai")，不要依赖系统默认时区，避免不同部署环境的时区配置导致计算结果不一致
• 如果业务存储的时间基准是UTC时区，直接使用Instant类型做时间累加会更简单，Instant表示UTC时间线上的瞬时点，本身不受任何地区夏令时规则影响：

public Timestamp addMinutes(long minutes, Instant recordInstant) {
    return Timestamp.from(recordInstant.plus(Duration.ofMinutes(minutes)));
}

• 禁止直接用LocalDateTime的plusXxx方法处理跨夏令时、跨时区的时间计算，这类方法仅适合无时区概念的字面时间运算场景。

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