Go 的 time 包在解析重复本地时间（如夏令时结束时的 1:59 AM）时默认选择后一个时刻，导致跳过时钟回拨过程；需通过非模糊起始时间 + 显式偏移来准确模拟 DST 过渡。
go 的 `time` 包在解析重复本地时间（如夏令时结束时的 1:59 am）时默认选择后一个时刻，导致跳过时钟回拨过程；需通过非模糊起始时间 + 显式偏移来准确模拟 dst 过渡。
在使用 Go 处理时区（尤其是涉及夏令时 DST）的场景中，一个常见误区是直接解析处于“重复小时”内的本地时间（例如莫斯科于 2014 年 10 月 26 日凌晨 2:00 回拨至 1:00，导致 1:00–1:59 出现两次）。此时 time.ParseInLocation 不会报错，但会静默选择该时间点的“后一次出现”（即 DST 结束后的标准时间），从而掩盖真实的时钟回拨行为。
以原问题为例：
loc, _ := time.LoadLocation("Europe/Moscow")
testz, _ := time.ParseInLocation("2 Jan, 2006 3:04pm", "26 Oct, 2014 01:59am", loc)该调用实际返回的是 DST 已结束、UTC+3（MSK）下的 1:59 AM（即 2014-10-26 01:59:00 +0300），而非 DST 尚存、UTC+4 下的前一个 1:59 AM。因此后续 Add(time.Minute) 始终在标准时间轨道上递增，无法观测到从 +04 → +03 的偏移跳变。
✅ 正确做法：避开模糊时间，从唯一时间点出发，显式构造过渡序列。例如：
const timeFormat = "2 Jan, 2006 3:04pm"
loc, _ := time.LoadLocation("Europe/Moscow")
// 使用 00:59 AM（DST 仍生效，唯一且明确）
testz, _ := time.ParseInLocation(timeFormat, "26 Oct, 2014 00:59am", loc)
fmt.Printf("%v → %v\n", testz, testz.UTC()) // 2014-10-26 00:59:00 +0400 MSK → UTC
// 加 1 小时：跨越 DST 结束边界（00:59 → 01:59 DST → 01:00 标准时间）
testz = testz.Add(time.Hour)
fmt.Printf("%v → %v\n", testz, testz.UTC()) // 2014-10-26 01:59:00 +0400 MSK → UTC
testz = testz.Add(time.Minute) // 此时进入标准时间：02:00 不再存在，而是 01:00
fmt.Printf("%v → %v\n", testz, testz.UTC()) // 2014-10-26 01:00:00 +0300 MSK → UTC
testz = testz.Add(time.Minute)
fmt.Printf("%v → %v\n", testz, testz.UTC()) // 2014-10-26 01:01:00 +0300 MSK → UTC输出将清晰呈现偏移变化：
2014-10-26 00:59:00 +0400 MSK → 2014-10-25 20:59:00 +0000 UTC 2014-10-26 01:59:00 +0400 MSK → 2014-10-25 21:59:00 +0000 UTC 2014-10-26 01:00:00 +0300 MSK → 2014-10-25 22:00:00 +0000 UTC 2014-10-26 01:01:00 +0300 MSK → 2014-10-25 22:01:00 +0000 UTC
⚠️ 注意事项：
- Go 的 time.Location 依赖系统时区数据库（IANA tzdata），确保运行环境已更新至支持目标年份 DST 规则的版本（如 2014 年莫斯科确实于 10 月 26 日 2:00 回拨）；
- 永远避免直接解析 01:xx（在回拨区间）或 02:xx（在向前跳跃区间）等模糊时间字符串；
- 如需验证某地 DST 行为，可结合 loc.GetOffset(t) 手动检查特定时间点的 UTC 偏移；
- 在 Web/API 场景中，建议统一使用 UTC 存储与传输时间，仅在展示层按需转换本地时间。
掌握这一机制，才能让 Go 程序真正可靠地应对全球复杂的时区变迁。
