每年九月底十月初，北半球的夏令时切换季一到，程序员社群里就会准时复发一种老病：定时任务跑重了、日历提醒晚了一小时、凌晨的日志"消失"了一截。这时候，一条2013年上线的老视频总会被资深工程师重新翻出来，甩进新人群里，配一句“先看完这个再写时间代码”——这就是Computerphile频道的《The Problem with Time & Timezones》，主讲人是英国科技内容创作者Tom Scott。选这条片子不是因为它新，恰恰是因为它讲的问题十年未愈：2022年国际计量大会已通过决议要在2035年前废除闰秒，欧美废除夏令时的立法却双双搁浅——时间规则的“政治属性”反而愈演愈烈。这条视频只用了十分钟，却把工程师处理时间的三大认知误区一次拆穿。本文把它拆开揉碎，再补上2013年之后发生的新证据，让你没看过视频也能懂，看过视频能多懂一层。
| 项目 | 内容 |
|---|---|
| 视频标题 | The Problem with Time & Timezones（时间与时区的问题） |
| 频道 | Computerphile（计算机科普频道，百万级订阅，以频道页面为准） |
| 主讲 | Tom Scott（英国科技创作者，客座讲解） |
| 上线时间 | 2013年（据频道页面） |
| 时长 | 约10分钟（据频道页面） |
| 播放量 | 数百万量级（以YouTube页面实时数据为准） |
| 链接 | https://www.youtube.com/watch?v=-5wpm-gesOY |
视频的第一个反转出现在开场三十秒（视频原片）。大多数人以为，时间处理是个“有点繁琐的数学问题”——无非是加减偏移量。Tom Scott给出的答案恰恰相反：日期和时间之所以是计算机领域最难缠的问题之一，是因为时区规则由各国政治决定，而且随时会变。数学题有唯一解，政治题没有：一个国家的政府可以出于贸易、宗教、能源或纯粹的民族情绪，在任何时候修改本国的时钟规则，而且往往只提前几个月通知。全世界的软件系统，都必须在这套“随时可能被改写的规则”之上做计算。这个开场定性，是整条视频所有论证的地基。
全片最震撼的案例是南太平洋岛国萨摩亚（视频原片）。2011年底，萨摩亚政府决定把整国时区从UTC-11调整到UTC+13——为了和国际日期变更线东侧的澳大利亚、新西兰做生意的时差更方便。操作方式简单粗暴：2011年12月30日这一天，从萨摩亚的日历上直接删除。12月29日过完，第二天睁眼就是12月31日。这一天出生的人“没有生日”，正在这两天之间预订酒店、办婚礼、订机票的人全部遭殃，全球日历和订票系统一片混乱。
（本文补充背景）这不是段子，是可查证的真实事件：时任萨摩亚总理图伊拉埃帕力推此案，理由是萨摩亚与新西兰、澳大利亚的贸易远多于美国西海岸，跨过日期线能减少一个整天的时差成本。对程序员来说，这个案例的杀伤力在于：它证明了一个国家的UTC偏移量不仅会变，而且可以整段跳变，甚至“回放”或“快进”到另一个日期。任何把“本地时间+固定偏移”写死在数据库里的系统，在2011年12月30日那天，萨摩亚的数据全是错的。
第二个案例更贴近每个开发者的日常：夏令时切换（视频原片）。以英国为例，每年十月底的一个周日凌晨，时钟回拨一小时——于是凌晨1:30这个时刻，会真实地发生两次：一次在夏令时里，一次在标准时间里。反过来，每年春季时钟拨快的那一夜，某个人们选定的时刻（比如凌晨1:30）则根本不存在——1点跳到2点，中间被整段跳过。
这两件“小事”把三类常见bug全部引爆：重复执行（同一个定时任务在回拨夜跑两遍）、凭空蒸发（拨快夜安排的凌晨任务永远没有执行）、以及歧义（日志里两条“凌晨1:30”的记录，到底是哪一次？）。视频用白板把这些场景一一推演，结论指向同一个方向：只存“几点几分”甚至只存“本地时间+固定偏移”，在这些边界上必然出错。
视频后半段给出正面解答（视频原片）：正确的心智模型是——时区不是"UTC+8"这样的数字，而是一整套持续更新的历史规则档案。“某个地区现在用哪个偏移、什么时候切换夏令时、历史上每一年的规则是什么”，这些信息被打包在一个持续维护的规则库里，全球所有系统都要跟着它同步更新。数据库里应该存的是UTC时刻，需要表达“未来的本地时间”时，存的应该是“本地时间+时区标识”，由规则库在运行时换算——因为谁也无法保证规则明年不变。
（本文补充）Tom Scott在片中反复强调的这套机制，对应的正是真实的IANA时区数据库（tz database，业内俗称Olson库）——它由Arthur David Olson等人从上世纪八十年代开始维护，如今由IANA官方托管，是Linux、Java、Python、手机操作系统共同的时间规则源头。这条视频的过人之处在于：它没有停留在“吐槽时区很乱”，而是把正确的工程方案（存UTC、存时区标识、依赖规则库）完整讲了一遍。
视频收尾浓缩成行动建议（视频原片）：数据库里存UTC；别自己发明时间运算；把时间规则库当作需要持续更新的“活数据”来对待，而不是一次写死、终身不变的常量。配合开场的“政治题”定性，全片形成闭环：规则会变→规则以时区标识+规则库表达→时刻以UTC存储→换算交给运行时规则库。
IANA时区数据库。 这是全片最硬的实体锚点。tz数据库收录了全球数百个时区自1970年（数据库纪元）以来的完整规则史，甚至包括南极为科考站单设的时区。它还有一段惊险往事（本文补充）：2011年，因有占星师团体以数据库收录“历史时区名称”为由威胁法律诉讼，维护者一度宣布停更撤库，整个互联网的软件供应链紧急自救，最终由IANA在2011年10月正式接管托管至今。这段历史反过来印证了视频论点：时间规则是“公共基础设施”，脆弱又致命。
ISO 8601与RFC 3339。 工程界表达时间的通用语言。ISO 8601是国际标准化组织制定的日期时间表示法（如2026-09-30T12:00:00Z，Z代表UTC），RFC 3339则是互联网领域的实施细则。两者规定了“如何书写一个时刻”，而IANA库规定“如何换算到某地本地时间”——前者是语法，后者是语义，缺一不可。
Unix时间与2038问题。 多数系统内部用“自1970年1月1日零点起的秒数”存时刻。但32位有整型计数器将在2038年1月19日凌晨溢出归零——这就是著名的Y2038问题（本文补充）。它是对“时间戳万能论”的直接提醒：Unix时间只表达“时刻”，不表达人类的日历语义，而且连它自己也活在存储位宽的刀刃上。
闰秒血案与2035大决议。 UTC为保证与地球自转对齐，自1972年以来插入过27次“闰秒”（截至2016年底，此后未再插入）。2012年6月30日那次闰秒夜，Linux内核的一个bug导致Reddit、Mozilla、LinkedIn等网站集体宕机，澳洲航空的订票系统瘫痪、多架航班延误（据当时媒体报道）。工业界随后普遍采用“闰秒抹平”（leap smear）——把多出的一秒摊进24小时里，谷歌等云厂商长期使用此法。2022年11月，第27届国际计量大会通过决议，要求在2035年前找到废除闰秒的方案——这是视频上线后该领域最大的制度变革。
2007年美国夏令时新政。 美国2005年通过能源政策法案，自2007年起把夏令时起始日期整体提前和推后数周，结果大量硬编码了旧规则的日历软件、日程系统集体出错，被业内称为“迷你Y2K”（本文补充，事件有广泛报道）。这是“规则随时会变”最具象的商业注脚：规则一改，全球软件都得连夜升级tzdata。
“程序员对时间的错误信仰”清单。 2011年起在程序员社区流传的《Falsehoods Programmers Believe About Time》清单，罗列了四十多条被现实反复证伪的天真假设：“一天有24小时”“时差永远是整小时”（尼泊尔是UTC+5:45）、“每个月天数固定”“未来时区规则不会变”……这份清单与视频互为表里，堪称时间处理的《劝退大全》。
工具的世代更替。 视频之后，工程界把“别手搓时间运算”产品化了：Java 8引入由Joda-Time作者Stephen Colebourne主导的java.time，.NET界有Jon Skeet维护的Noda Time，Python标准库收录了绑定IANA库的zoneinfo，JavaScript生态的Temporal提案也已进入ECMAScript标准流程后期。这些库的共同设计正是视频主张的落点：区分“时刻”与“本地时间”，换算一律交给规则库。
站得住的部分。 “时区是政治产物、规则会变”是全片核心，也是证据最强的部分：萨摩亚删日（2011）、美国改夏令时规则（2007）、欧盟2019年表决通过废除年度调钟却因成员国分歧搁浅、美国参议院2022年全票通过“永久夏令时法案”却卡在众议院（以上均为可查证的公开事件）——十年间每一件大事都在为这条论点续命。可以说，视频的核心主张不是观点，是不断自我实现的事实。
需要补丁的部分。 第一，“一律存UTC”是必要条件而非充分条件。对于未来的本地日程（每周一早九点的例会、明年三月的闹钟），只存UTC是错的——规则一变，UTC就错了；正确做法是存“本地时间+时区标识”，这正是视频自己也强调的细节，但常被转述者丢掉。第二，视频未涉及夏令时回拨夜的歧义本地时间（发生两次的时刻）与拨快夜的空洞时间（不存在的时刻）在API层如何显式建模，现代类库（如java.time的Offset类型、Temporal的ExactTime语义）才有完整答案。第三，“Unix时间戳包打天下”如果被理解成视频主张，就偏了——日历的“加一天”不等于“加86400秒”，人类的月、周、节假日语义需要日历模型而非纯秒数运算。
时效性注记。 视频讲闰秒时还是“现有制度”，如今制度已判死缓（2035年改革窗口）；讲夏令时时欧洲改革未起，如今改革搁浅——工具和制度都变了，但“规则会变”这个元命题从未变过。用2026年的眼光重看，这条2013年的视频不仅没过时，反而因为后续十年续集不断，论证更完整了。
第一，把时间当“带版本号的活数据”，而不是常量。 时区规则库（tzdata）需要像依赖包一样定期升级。你的服务器、容器镜像、手机、数据库，各自的tzdata版本可能不同——同一个未来日期，在不同版本的规则下换算结果可能不一样。工程动作很具体：把tzdata升级纳入和依赖升级同级的例行维护清单。
第二，用一条铁律设计数据模型：时刻存UTC，日程存“本地时间+时区标识”。 对外交换一律使用ISO 8601/RFC 3339格式的UTC字符串（带Z），内部计算全部转成UTC；凡是“未来的、按当地时间重复的”事件，必须同时保存IANA时区名（如Asia/Shanghai），绝不允许只存固定偏移量。这条铁律能一次性规避萨摩亚式跳变和夏令时边界这两大类事故。
第三，用测试钉住时间边界。 时间bug最阴险之处在于一年只犯一次。给每个涉及时间的模块写两个固定用例：一个落在春令时“不存在的时刻”上，一个落在秋令时“重复的时刻”上——用例在规则库升级后依然全绿，才算合格。选择任何主流类库（java.time、Noda Time、zoneinfo、Temporal）都好过自己写一行时间算术。
flowchart TD
A["直觉：时间是数学题"] --> B["真相：规则由政治决定"]
B --> C["萨摩亚：一整天被删除"]
B --> D["夏令时：1:30出现两次"]
B --> E["规则库持续更新"]
C --> F["偏移量会过期"]
D --> F
E --> G["时区是规则集"]
F --> H["时刻：存UTC"]
G --> I["日程：本地时间加时区名"]
H --> J["落地：成熟类库与tzdata"]
I --> J
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。