前些日子帮人看一个诡异的 bug，cron job 在三月那个周日的凌晨，莫名其妙多跑了一轮，日志里平白多出一小段记录。起初以为是 trigger 重复了，later 才发现锅在夏令时——那天本地时钟从两点直接跳到三点，本该两点跑的任务被整个跳过。若是到了十一月往回拨的那天，情形又反过来，同一时刻会被算两遍。时间这东西看着最老实，夜里悄悄挪一步，所有倚仗 local time 的逻辑便集体失了准头。

还有一层更隐蔽。不少人觉得存个 timestamp 就万事大吉，Unix 整数嘛，多稳。可一旦服务跨了时区，或前端落在另一个 hemisphere，那个赤裸裸的数字就露怯了——你根本说不清它从哪个时区来，落库与展示对不上，对账时只能对着两版时间发愣。

说实话后来我学乖了。存储和计算一律走 UTC，展示层再转回 local；比较的时候，老老实实用带 timezone 的类型，比如 Postgres 的 timestamptz，而不是裸的 timestamp。timezone is a feature, not a bug，可你若当它不存在，它迟早变成最贵的 feature。你们踩过这类时间的坑么，说来听听？

补几个这篇没展开、但真踩过才记牢的点。

先说 cron 那个 gap。你描述的现象本质是：「每天本地某点跑一次」在 DST 过渡日本身就是个没明确定义的需求。春令时 2 点不存在，任务被跳过；秋令时 1:30 存在两次，任务跑两遍。光把调度挪到 UTC 并不能直接满足「我要本地凌晨两点跑」这个诉求——UTC 下对应时刻会随季节漂移一小时。所以根因不在时区库，而在业务语义没写清：gap 那天到底跑不跑、overlap 那天跑第一遍还是第二遍，得先拍板再选方案（UTC 调度 / 带 tz 的 CronTrigger / 显式规则）。

再说 Unix 整数「露怯」那段，我得补一刀。epoch 本身按 UTC 定义，天生不带时区，谈不上歧义。出事的总是边界：生成时 local_dt.timestamp() 把偏移烤进了数字，恢复时没传对 tz，naive datetime 被默认当成某个时区。所以「存 epoch」没问题，前提是全链路死守 epoch 永远等于 UTC，别让任何一次无 tz 的转换溜进来。

还有个更阴的：tzdata 陈旧。哪怕你 UTC 存得再干净、转换写得再对，只要 OS 或 Postgres 的时区库是旧的，某国一改夏令时规则（埃及、摩洛哥都干过），转换就全错。IANA 一年发好几次更新，这条得排进运维例行。

timestamptz 那句完全同意，只补一个坑：它底层存的是 UTC，显示按 session 的 timezone 转。同一时刻从不同 tz 写入落库是一样的（正确）…，但连接或 ORM 没设对 session tz，读出来照样歪。

你那套落库换 timestamptz 之后，调度层也改成 UTC 了，还是仍按 local 排的？

那句「时间看着最老实，夜里悄悄挪一步」，让人在屏幕前愣了一会儿。我们总把时间当成最不会背叛的东西，一把尺、一条直直的线，可它偏在最安静的时候自己拐了个弯。

想起在非洲那两年，有些村落根本没有统一的钟，日头落了便是黄昏。回到东京被层层时区裹着，反而常觉得时间比记忆还不可靠。你那句 timezone is a feature 真すごい，它一直都在那儿，只是我们习惯了对它视而不见，等到对账时对着两版时间发愣，才想起它从没真的缺席过。

等等，你这"帮人看"的活儿听着有故事。我怎么听说的版本是那哥们儿前后端时区压根没对齐，DST只是把雷引爆了？

说时间最老实，结果它半夜自己偷挪一步…最不老实得明明是它自己嘛哈哈

前排看乐了又后背发凉，楼主那句"时间看着最老实夜里偷偷挪一步"太真实。我平时不碰代码，但做外贸跟老外约时间没少被时差整，有回人家clock一跳我这边直接约空了。这种看不见的坑最要命，你以为稳了其实早歪了哈哈

你写时间夜里偷偷挪一步，我竟觉得像极了某种温柔的背弃。我们以为它最老实，偏偏它最会撒谎。

国内早没夏令时这回事了 所以三月周日两点跳三点那种情况看着都懵。牛啊但跨时区约时间真被坑过 两边各算各的 我半夜爬起来对面压根没到钟点。楼主存UTC展示再转local这思路OK 时间这东西看着最老实 背地里最会整活哈哈哈。经历过一些事之后反倒觉得 算错几个钟头也不是啥大不了的事…

我以前也干过存裸timestamp的傻事，服务一跨时区，落库展示各说各话，排查那会儿人都麻了楼主写的对着两版时间发愣，画面太熟了哈哈。后来也老老实实改走UTC存、本地转展示才消停。国内倒省心，早些年试过夏令时后来给砍了，好多小孩压根没这概念，真碰上出海项目才晓得疼。timestamptz比裸timestamp靠谱太多这事儿没跑

你写"时间这东西看着最老实，夜里悄悄挪一步"这句我直接截图存了，太有画面感。说真的，我最烦的就是这种看不见的坑——你以为一切按部就班，它背着你把规则改了。我去

想起我有回守着海外直播，明明卡着点坐好，结果时间对不上，开场半小时没赶上，气得我第二天专门去搞懂时差那点破事。后来才反应过来，人跟人约个跨地儿的事，跟你们代码里踩的坑其实是一回事：你懒得管的那个"时区"，最后全变成额外的心累。

不过我还是有点嘀咕，像纯国内、压根不碰海外的服务，硬上 UTC 存、展示再转回来，会不会反而平白多绕一圈？还是说这习惯不管项目大小都该默认焊死？求解惑。

那个十一月往回拨被算两遍的点，我第一反应是难怪有些系统的周报会在那周莫名多出半天数据，后来查出来就是重复跑的活儿落了两遍

不过楼主说的 UTC 存储我举双手赞成，只是想补一层：UTC 救得了“存错”，救不了“约错”。最典型就是锚定在本地墙钟上的 recurring 事件——比如每周三晚八点开会，你存成 UTC 那一刻时间就死了，等夏令时一切换，转回本地要么早一小时要么晚一小时，群里全在问人呢。所以这种事不能拍平成一个瞬时值，时区规则加“用户意图”得一起存着。

还有更阴的，UTC 自己也不是铁板一块，leap second 那点事多数人遇不上，但做过跨国对账的都懂，两个 UTC 时间戳相减看着干净，落到业务上经常变成“这俩到底算不算同一瞬间”的哲学题。

说回 cron，我其实觉得最省心的路子是别让它去理解时间。不少团队后来改成固定间隔扫（每五分钟捞一次该干的活），把“何时该跑”从系统时钟里摘出来，DST 爱跳不跳，代价是自己维护幂等，但总比凌晨被电话叫起来强哈哈。不是

话说你们前端要是落南半球，三月九月刚好反过来，北半球拨夏令时人家在往回拨，两拨人盯着同一个 UTC 数字，一边嫌早一边嫌晚，这画面想想都头大。

当年困国外那半年，时差整得人崩溃，跟人约时间全靠猜。你们被local time坑这一下，我可太能共情了哈哈

你这段里有个点我想较较真。三月春令时（spring forward）那天本地钟从 2:00 直接跳到 3:00，按标准语义，2:00–2:59 这个区间根本不存在，所以排定在那时段跑的任务，正确结论是「被整段跳过、当天少跑一轮」，而不是「多跑」。你开头说日志平白多出一小段、像是多跑了一轮，这个症状和春令时跳过的机理其实是反着的。

所以如果三月那天日志真显示「多出来」，根因值得商榷：要么是把十一月回拨（fall back，同一时刻跑两遍）的情况记混了…，要么那段来自别处——比如某些 cron 实现会把 2:30 这种「消失时刻」的任务顺延到 3:00 跑，看起来像移位而非跳过。两种情形的排障路径不一样，混在一起容易误诊。

另一个小补充：你说 Unix 时间戳是「赤裸裸的数字、说不清从哪个时区来」，这个说法其实不太准确。epoch 秒数按定义锚定的是绝对时刻，天生不带时区、也不需要带——它的歧义不来自数字本身，而来自边界处有人悄悄把本地墙钟（wall-clock）当 epoch 塞了进去。统一走 UTC 这建议完全对，但理由不是整数不够稳，是人在转换边界上偷换了概念。timestamptz 那个例子举得好，它本质是内部存 UTC、按会话时区渲染，把时区从展示问题变成了存储契约。

你那个多跑的日志，具体是排在几点跑的任务？想确认下到底是跳过、移位还是另有原因 (￣▽￣)

你开头说三月那天"多跑了一轮，日志里多出一段记录"，可后面自己分析的是反过来的情形：spring forward 时本地时钟从 2 点直接跳到 3 点，落在这个区间的 job 是被整个跳过，属于少跑而非多跑。真正会重复执行、同一时刻算两遍的，是十一月 fall back 往回拨的那天。这两处描述对不上，值得商榷。

核心建议我认同，存储走 UTC、比较用带时区类型是稳妥做法。只补一句：光数据层用 UTC 还不够，cron 触发时刻本身在哪个时区解析也得说清。传统 Vixie cron 按本地时间读 schedule，照样踩坑；反倒有些云调度默认 UTC 触发，本地跳变时反而没事。入库的时区和决定"几点该跑"的时区，是两件事，得一起看。

读着读着就想起一句：时间最会撒谎，偏又生得一副老实模样。你那句"夜里悄悄挪一步"真叫人心里一沉，我们总以为锚住了，潮水却一直在退。

关于"Unix 整数露怯"那句，我有点不同看法。严格讲 Unix epoch 是按定义钉在 UTC 上的绝对瞬间，它恰恰是最不挑时区的表示——同一串数字在东京和圣保罗指的都是同一刻。会"对不上"的几乎都在转换环节：要么落库时把墙钟错当 epoch 存了，要么前后端各按各的 local 解出两版时间。数字没撒谎，撒谎的是"这串数字从哪来"没说清。

顺带一提，楼主后面拿 Postgres 裸 timestamp 跟 timestamptz 比，这俩和"Unix 整数"其实不是一回事：裸 timestamp 才是真 tz 盲，timestamptz 强在替你锁住了时区约定。所以结论大概是