第2章时间基础概念

一、时间基础概念：UTC、GMT、TAI、本地时间、时区、闰秒

做分布式系统，时间是个绕不开的坑。

我刚开始接触时钟同步时，觉得时间嘛，不就是看表吗？后来被坑了几次才明白——时间这玩意儿，远比想象中复杂。你想想看，全球几十亿台设备要协同工作，如果各自的时间基准都不一样，那不乱套了？

这一节，咱们先把时间的基础概念捋清楚。说白了，就是搞懂时间到底是怎么定义的，以及我们日常用的那些时间术语到底啥意思。

先说 GMT。全称是 Greenwich Mean Time，格林尼治标准时间。它最早源于英国皇家格林尼治天文台的观测。怎么测的呢？就是看太阳经过本初子午线的时间。

嗯，这里要注意：GMT 本质上是一种天文时间。它基于地球自转来定义。但问题来了——地球自转并不均匀。它一直在减速，而且还有各种不规则的抖动。

我在项目中遇到过一台老设备，它的时间源就是 GMT。结果呢？每天误差能到几十毫秒。对于普通应用可能无所谓，但做金融交易系统，这误差就致命了。

关键点：GMT 是基于地球自转的天文时间，精度有限，不适合高精度分布式系统。

UTC 是目前全世界通用的时间标准。全称是 Coordinated Universal Time，协调世界时。

它跟 GMT 有啥区别？简单说：UTC 是原子钟时间，GMT 是天文时间。原子钟的精度比地球自转高了好几个数量级。铯原子钟的误差大约是每 3000 万年才差 1 秒。

我个人习惯把 UTC 理解为「全球时间的锚点」。所有时区、所有系统，最终都要对齐到 UTC。你手机上的时间，底层也是 UTC，只是显示的时候加上了时区偏移。

避坑指南：我曾经在配置 NTP 服务器时，误把 GMT 和 UTC 当成一回事。结果系统时间跟标准时间差了 0.9 秒。虽然不大，但对于需要微秒级同步的场景，这就是灾难。记住：生产环境永远用 UTC，别用 GMT。

TAI，International Atomic Time，国际原子时。它完全基于原子钟的物理特性，不依赖地球自转。

说白了，TAI 是「最诚实」的时间。它一秒一秒地走，从不调整。但问题来了——地球自转在变慢，所以天文时间（UT1）和原子时（TAI）之间的差距会越来越大。

目前这个差距是多少？大约 37 秒。而且每年还在增加。

闰秒是个很有意思的东西。它存在的意义，就是让 UTC 和天文时间（UT1）不要差太远。

规则是这样的：当 UTC 和 UT1 的差距超过 0.9 秒时，就在 UTC 中插入或删除 1 秒。通常是 6 月 30 日或 12 月 31 日的最后一分钟。

你想想看，这 1 秒插入进去，系统时间就变成了 23:59:60。很多软件根本处理不了这个「第 60 秒」。

我曾经踩过的坑：2016 年底那次闰秒，我们有个数据库集群直接挂了。原因是时间回跳了 1 秒，导致主从复制的时间戳出现冲突。从那以后，我建议所有关键系统都采用「闰秒平滑」策略——把这一秒的调整分散到 24 小时内，而不是瞬间完成。

本地时间 = UTC + 时区偏移。就这么简单。

但实际落地时，坑很多。比如夏令时。有些国家实行夏令时，有些没有。同一个时区，不同季节的偏移量还不一样。

我个人建议：所有系统内部统一用 UTC，只在展示给用户时转换为本地时间。这样能避免大量时区相关的 bug。

实用建议：代码中永远不要手动计算时区偏移。用现成的库，比如 Python 的 pytz、Java 的 ZoneId、Go 的 time.LoadLocation。我见过太多手写时区计算导致的时间错误了。

下面这张图，把上面讲到的所有时间概念串起来了。你可以看到它们之间的关系：

这一节的内容，说白了就是搞清楚时间到底是怎么定义的。我个人的经验是：理解这些基础概念，比学会配置 NTP 更重要。因为只有理解了「时间是什么」，你才能在设计分布式系统时做出正确的决策。

记住几个关键点：

一句话总结：时间同步的第一步，不是配置服务器，而是选对时间标准。选 UTC，准没错。

公众号：蓝海资料掘金营，微信 deep3321