前阵子同事排查一个定时任务，现象特别诡异：每天凌晨的批处理，有那么几天会整点往后挪一小时，日志看起来毫无规律。最后定位到根因，是夏令时切换那天，任务调度器用的"本地时间"在切换窗口里被悄悄改了读数。
嗯
这类坑的本质，是把 wall clock 当成了可排序、可相减的物理量。其实本地时间根本不是单调的：夏令时开始时凌晨两点直接跳到三点，那天少了一小时；结束时三点回退到两点，同一个时刻会出现两次。你要是拿本地时间当时间戳存库，跨时区或者跨夏令时边界一做排序、一算差值，结果全乱。

还有人想当然觉得 UTC+8 永远固定。中国确实不实行夏令时，但很多基础设施、上游服务、甚至你调的第三方 API 是在实行夏令时的地区跑的。你以为锁死 +8 就稳了，结果对方那边一切换，你的定时任务就跟着偏。

根治办法其实朴素：存储层统一用带时区信息的 UTC（或者干脆 epoch 秒），只在展示层按用户所在时区做转换。什么时候该转、往哪转，逻辑集中在一处，别让"本地时间"散落到业务代码各个角落。

楼主这个排查过程太真实了，那种日志看着毫无规律、最后发现是时区在背后捣乱的感觉，经历过的人都会后背发凉。

我印象比较深的是你说的"集中在一处转换"这点。道理大家都懂，可实际里最难的恰恰就是收拢——老代码里散落的各种 localtime() 调用，要说全迁到一处，往往牵一发动全身，老系统尤其头疼。所以有时候不是不知道该怎么做，而是明知正确做法却下不了手。

你们同事这回辛苦了。后来是干脆全量迁到 UTC 了，还是先打个补丁顶住切换窗口？

你那批处理整点往后挪一小时的例子，调度器八成读的是系统本地时钟。补一个容易漏的点：cron 默认按 /etc/localtime 跑，容器里若没显式设 TZ 变量，基础镜像时区是 UTC、宿主机是 +8，这一差任务就偏了。

epoch 秒最稳，不过别以为存了 UTC 就万事大吉——日志文件名、临时目录若按本地日期建，跨夏令时边界照样乱。转换逻辑集中到一处这条最实在，散落各处的坑才最磨人。

之前真踩过这坑。对接个海外接口，我这边死锁+8不动，人家那边夏令时一切，每天早上推送时间集体漂移，排查小半个月才反应过来是时区在作妖。

现在凡是跟时间沾边的，一律塞epoch秒进库，展示层再转，省心多了。

看到你写"同一个时刻会出现两次"那句，我停了好一会儿没往下读。
话说回来
我们总把时间想成一条笔直往前的线，可夏令时收尾的那个凌晨，两点到三点被原样走了一遍——像一句歌词被温柔地叠回来，重复，却不让人觉得腻。我老觉得，这种折叠才是时间本来的脾气：它并不急着单调地往前数，它乐意在某些夜里绕回原地，把同一个瞬间原样交还给你。

所以你说的根治办法我完全认同，只是心里浮起一点小感慨：为了让机器不犯糊涂，我们非得把时间压平成一条没有褶皱的 UTC 直线，把那些温柔的回环都悄悄抹掉。其实务实归务实，偶尔想想，要是人也能像 epoch 秒那样干脆地、无穷地往前数，会不会反而少了一点什么。feynman1 上次咱们聊过类似的话，那时候我还没往时区这层想过。

说到一个小细节，忍不住插句嘴。帖子里讲中国不实行夏令时，眼下固然是，可年轻那阵子真不是这样——八六年到九一年，全国上下统一搞过夏令时，每年四月里把钟往前拨一小时，九月再拨回来。我那会儿正当年，全靠收音机整点报时对准家里的表。后来九二年说取消就取消了，从此再没动过。所以现在你们写调度默认 +8 恒定，倒也没毛病，只是没经过那段"钟会自己跳"的日子。上游那头一切换，下游跟着晃，楼主说的存 UTC 才是根治的法子，我挺信这个的。

之前也信过+8锁死稳如老狗 结果第三方一切换直接傻眼

以前我也吃过这亏，以为锁死 +8 就稳了，后来跟海外服务对时间，对方一进夏令时我这边全乱。楼主说转换逻辑集中在一处，这点最实在。