Go 时间DST 切换日加一天结果异常怎么办

Go 里“加一天”并不只有一种含义。对带有真实时区 Location 的 time.Time 使用 AddDate(0, 0, 1)，表示日历日期向后移动一天；如果这一天跨过夏令时（DST）切换，两个时刻的绝对间隔可能是 23 小时或 25 小时。业务若要求严格增加 24 小时，应使用 Add(24 * time.Hour)。

官方资料：https://pkg.go.dev/time

排查这类异常时，先确认业务要的是“同一当地时刻的下一天”，还是“经过固定时长后的时刻”，再确认输入是否携带了会变化的时区规则。不要把打印出来的日期相同，误认为经过的秒数也一定相同。

先确认异常是日历语义还是固定时长语义

下面的例子把两个操作放在同一个带有欧洲时区规则的时间上。示例输出是依据 Go 官方 time 文档中 DST 例子的推导结果，不是本文制作过程中的本地运行截图。

package main

import (
    "fmt"
    "time"
)

func main() {
    zurich, err := time.LoadLocation("Europe/Zurich")
    if err != nil {
        // 时区数据不可用时不要静默退回机器默认时区。
        panic(err)
    }

    start := time.Date(2023, time.March, 25, 12, 0, 0, 0, zurich)
    calendarDay := start.AddDate(0, 0, 1)       // 保持当地钟表时间为第二天12点。
    fixedDuration := start.Add(24 * time.Hour) // 固定增加86400秒。

    fmt.Println(calendarDay)
    fmt.Println(fixedDuration)
    fmt.Println(calendarDay.Sub(start), fixedDuration.Sub(start))
}

这个日期正好靠近 Zürich 的春季切换。按官方示例的语义，AddDate 的结果仍是第二天 12:00，但它与起点的间隔可能为 23h0m0s；Add(24 * time.Hour) 则一定经过 24 小时，显示的当地钟表时间可能不同。两者都没有“算错”，只是契约不同。

因此，账单有效期、自然日提醒、按当地日期生成报表，通常先考虑 AddDate；令牌过期、超时、重试间隔、租约持续时间，通常先考虑 Add。如果需求文档只写“加一天”，应先把这个语义补清楚。

用真实 Location 保留 DST 规则

DST 不是某个固定的“夏天多一小时”常量，而是由时区规则决定的变化。time.LoadLocation 加载的是带历史和转换规则的 IANA 时区；time.FixedZone 只表达固定偏移，不能替代会发生 DST 变化的地区规则。

func nextLocalDay(input time.Time, zoneName string) (time.Time, error) {
    loc, err := time.LoadLocation(zoneName)
    if err != nil {
        // 把时区加载失败交给调用方，避免用错误的默认时区继续计算。
        return time.Time{}, err
    }

    // 先把同一个瞬间转换到目标地区，再按当地日历加一天。
    local := input.In(loc)
    return local.AddDate(0, 0, 1), nil
}

这里的关键是先决定“业务所属的地区”，而不是用服务器的 time.Local 猜测。容器、开发机和生产机的本地时区可能不同；把时区名称作为配置或数据的一部分保存，通常比依赖运行环境更稳定。

还要注意持久化边界：Go 文档指出，部分时间编码只保存偏移而不保存 Location 名称。若后续还要按当地日历继续运算，建议把 UTC 瞬间与业务时区标识分开保存，而不是只留一个类似 +02:00 的字符串。

检查切换点的缺失与重复本地时间

DST 切换会产生两种特殊墙上时间：春季拨快时，一段本地时间根本不存在；秋季拨慢时，一段本地时间会出现两次。Go 的 time.Date 在这类不明确输入上会返回参与转换的某个时区结果，但官方文档不保证选择哪一个。不能只凭“年月日时分”推断唯一的绝对瞬间。

func describe(t time.Time) string {
    name, offset := t.Zone()
    return fmt.Sprintf("%s zone=%s offset=%d isDST=%t", t.Format(time.RFC3339), name, offset, t.IsDST())
}

// 构造切换附近的时间时，应把 Location 和偏移一起记录到排查日志。
func logBoundary(t time.Time) {
    fmt.Println(describe(t), "location=", t.Location())
}

排查时至少记录格式化后的时间、Zone() 返回的名称与偏移、Location()，并在支持的 Go 版本中记录 IsDST()。这样能判断问题是日历日期改变、偏移改变，还是输入本来就落在缺失/重复区间。

如果业务接收的是用户输入的“当地日期和时刻”，需要额外制定歧义策略：拒绝缺失时间、提示用户选择重复时间对应的偏移，或由产品规则固定选择。这个选择不能交给格式化字符串或服务器默认时区隐式决定。

统一比较、持久化和测试边界

两个 time.Time 可能使用不同 Location 或带有不同的单调时钟信息，但表示同一个瞬间。比较瞬间时优先使用 Equal，不要把 == 当成业务上的时间相等判断。若时间要作为数据库键或缓存键，也要先统一存储协议和精度。

func sameInstant(a, b time.Time) bool {
    // Equal 比较的是时间瞬间，不要求两者使用同一个 Location 对象。
    return a.Equal(b)
}

func addByContract(t time.Time, calendarDay bool) time.Time {
    if calendarDay {
        // 自然日业务跟随 Location 的日历规则，DST 日不强行补成24小时。
        return t.AddDate(0, 0, 1)
    }
    // 超时和租约按固定时长计算，不受当地钟表切换影响。
    return t.Add(24 * time.Hour)
}

测试不要只覆盖普通日期。至少准备：普通日、春季切换前一天、秋季切换前一天、缺失本地时间、重复本地时间，以及 UTC 作为对照。断言时分别检查格式化后的当地日期、Sub 的绝对间隔和 Equal 结果，避免一个断言同时承担两种语义。

两个容易混淆的问题

为什么同样是加一天，结果会差一个小时？ 因为 AddDate 按 Location 的日历规则移动日期，而 DST 让两个当地日期之间的绝对时长不再固定为 24 小时。差异来自时区规则，不是浮点误差。

改成 UTC 就能解决所有问题吗？ UTC 适合统一保存瞬间和计算固定时长，但它没有用户所在地区的当地日历语义。需要“当地每天某个时间”时，仍要保留目标 IANA 时区并在该 Location 下做日历运算。

归纳起来，先把“日历日”和“固定时长”写进接口契约，再让 Location 参与运算；遇到 DST 切换，分别核对当地表示、偏移和绝对间隔。这样“加一天结果异常”就能从模糊的时间问题，收敛成可判断的语义和边界问题。