Go 日期加一天跨夏令时为何不等于 24 小时

Go 的 AddDate(0, 0, 1) 增加一个日历日，Add(24*time.Hour) 增加固定的 24 小时。跨越夏令时切换时，本地日期与 UTC 偏移之间的对应关系变化，因此“明天同一钟表时刻”不一定距离现在 24 小时。

官方文档：https://pkg.go.dev/time#Time.AddDate。这不是加法精度问题，而是两种不同的业务语义。

先确定一天指的是日期还是时长

假设需要给跨地区用户计算“明天中午”的提醒时间。我会先写下用户所属时区和目标钟表时刻，而不是直接定义一个叫 day 的 24 小时常量。这里是一个用于讨论的需求场景，不是已经执行过的项目复盘。

对我来说，最值得纠正的直觉是把日历上的一天和秒数上的一天混为一谈。前者关注当地日期，后者关注两个时刻的实际间隔。固定时长适合“经过 24 小时后到期”；日历运算适合按某个地区的日期推进。两者在普通日期可能碰巧得到相同结果，不能据此断定可以互换。

固定示例的时区与起点

比较之前，先选一个带地区规则的 Location。示例使用 America/New_York，不依赖机器的 Local。不能只用名字叫“纽约”的 FixedZone 代替地区时区：固定偏移不会包含夏令时切换规则。

示例空白导入 time/tzdata，在系统缺少时区数据时提供内置后备数据；仍须处理 LoadLocation 返回的错误。它会增大可执行程序，通常由 main 包决定是否引入，而非要求所有库都强制打包。相关官方说明：https://pkg.go.dev/time/tzdata。

用同一个起点比较两种加法

将以下代码保存为独立目录的 main.go。它只计算并打印时间，没有定时任务、网络连接或待清理的文件资源。选择中午是为了把注意力放在间隔差异上，不把当地跳过或重复的凌晨时刻混入这个小例子。

package main

import (
    "fmt"
    "os"
    "time"
    _ "time/tzdata" // 系统没有时区文件时，提供内置后备数据。
)

func compare(label string, start time.Time) {
    // 两种计算均从同一个起点开始，避免串联运算。
    calendar := start.AddDate(0, 0, 1)
    duration := start.Add(24 * time.Hour)

    fmt.Println(label)
    fmt.Println("起点:", start.Format(time.RFC3339))
    fmt.Println("日历:", calendar.Format(time.RFC3339),
        "实际间隔:", calendar.Sub(start))
    fmt.Println("时长:", duration.Format(time.RFC3339),
        "实际间隔:", duration.Sub(start))
}

func main() {
    loc, err := time.LoadLocation("America/New_York")
    if err != nil {
        // 加载失败就退出，不悄悄改用机器本地时区。
        fmt.Fprintln(os.Stderr, "加载业务时区失败:", err)
        os.Exit(1)
    }

    // 使用历史日期，分别观察春季和秋季切换附近的计算。
    compare("春季样例",
        time.Date(2024, time.March, 9, 12, 0, 0, 0, loc))
    compare("秋季样例",
        time.Date(2024, time.November, 2, 12, 0, 0, 0, loc))
}

# 在保存 main.go 的示例目录中运行，不启动后台进程。
go run main.go

这里提供读者可运行的示例，没有声称已经在本机执行。阅读输出时，先比较 RFC3339 中的偏移，再看实际间隔，最后看小时字段；不要只截取年月日。

同时看时钟、偏移和实际间隔

若两个中午之间的偏移向前变化一小时，日历加一天对应的间隔便缩短为 23 小时；向后变化一小时则延长为 25 小时。代码中时长分支的间隔始终为 24 小时，但当地钟表读数可能变成 13 点或 11 点。这些是按对应时区规则推导的关系，不是发布前的实测数据。

并非每个地区都使用夏令时，也并非所有偏移调整都恰好一小时。我会让 Sub 的结果显示间隔，而不是写一个通用的“夏令时日一定 23 或 25 小时”判断。无偏移变化的日期，两个分支可能重合。

同一时刻转换到 UTC 只是换一种表示；先在 UTC 下做 AddDate，再转回业务时区，却已经把日历运算的地点换掉了。因此，“本地明天同一时间”和“UTC 明天同一时间”不是同一个约定。

把选择落回业务并保留边界约定

我会把实验改成业务用例时，先保留地区名、起点和目标语义，再做三组对照：切换附近日期、普通日期、UTC。这样更容易发现“程序正确计算了错误的业务问题”，而不只是盯着相差的一小时。

另一个需要单独决定的边界是当地不存在或重复的钟表时刻。AddDate 会按 Date 的方式构造结果；遇到夏令时跳过或重复的时刻，Date 不保证选取其中哪个相关时区。若业务坚持某个凌晨时刻，应约定跳过、顺延或重复时选择哪一个，不能仅靠 AddDate 自动得到唯一业务答案。实现参考：https://go.dev/src/time/time.go。

这个小实验结束后无需停止服务或关闭资源。用于真实系统时，我的取舍是：日历需求保留业务时区，固定时长需求保留 Duration；不要为了让两个结果一样而偷偷改成 UTC。本文不涉及调度器、月末规则或复杂时区政策的完整设计。

服务器使用 UTC，还能计算用户的明天吗？

能。先把起点置于用户的业务 Location 再做日历运算，结果可用 UTC 保存或传输；业务时区信息也需要在需求模型中保留。

AddDate 会修改原来的 Time 吗？

不会。它返回新的 Time。示例保留 start，是为了让两种加法共享完全相同的比较起点。

日期加一天为什么有时还是 24 小时？

如果所选时区在这段期间没有偏移变化，且目标钟表时刻不存在特殊歧义，日历日与固定 24 小时可以重合。重合只说明该案例一致，并不改变两个方法的语义。