标准时间如何确定 - UTC背后的国际体系
UTC并非由一台时钟产生,而是由全球80多个研究机构的数据经巴黎BIPM加权平均生成。本文讲解TAI、闰秒决策、从卫星到NTP的分发渠道,以及即将到来的秒的重新定义。
闰秒是插入 UTC 的调整,目的是使其与 UT1(基于地球实际自转的时间尺度)的偏差保持在 0.9 秒以内。自 1972 年 UTC 引入以来,到 2016 年底共添加了 27 个闰秒。它们以 23:59:60 的形式插入在 6 月 30 日或 12 月 31 日的 23:59:59 之后,这是正常计时中不会出现的异常秒值。
闰秒的需求源于地球自转并不恒定。潮汐摩擦正在逐渐减慢地球自转,长期来看每世纪使一天延长约 2.3 毫秒。来自构造运动和大气环流的短期变化也可能加速自转,因此闰秒之间的间隔不是固定的。从 1972 年到 1979 年每年都有闰秒;自 2017 年以来没有添加过,这反映了地球自转的暂时加速。
2022 年 11 月,第 27 届国际计量大会(CGPM)通过了一项决议,计划在 2035 年前停止插入闰秒。该决定反映了一个判断:闰秒对通信、金融和导航系统造成的运行风险,如今已超过保持民用时间与地球自转对齐的价值。
该决议允许 UTC 与 UT1 之间的差距增长超过一秒,并为未来几十年或几百年差距变得显著时进行更大规模的修正(例如闰分钟)留下了可能性。国际电信联盟(ITU)正在制定 2035 年前的实施细节,包括现有闰秒框架将如何在操作层面逐步退役。
闰秒对软件来说是个问题,因为 23:59:60 这个值在标准时间表示中是非法的。大多数软件假设每分钟 60 秒,无法表示或处理第 61 秒。2012 年的闰秒暴露了一个 Linux 内核 Bug,导致 Reddit、Mozilla、Foursquare 和其他主要服务在一次协调性事件中集体崩溃。
空中交通管制必须在闰秒边界精心管理 GPS 时间(不包含闰秒)与 UTC 之间的差异。金融市场以高精度为交易打时间戳,一秒钟的不连续性可能在闰秒期间扰乱交易顺序。正是这些风险促使大多数大型运营商多年来一直游说废除闰秒。
闰秒的主要变通方案是 Google 在 2008 年引入的“闰秒平滑”。它不是插入一个 23:59:60,而是在以预定闰秒为中心的 24 小时窗口内微微拉伸每一秒。每秒变长约八万六千四百分之一秒(约 11.6 微秒),将一秒钟的调整分散到整整一天。
亚马逊(AWS)和微软(Azure)使用类似的平滑技术,但各提供商的具体起始时间和持续时间有所不同。在闰秒附近比较不同云提供商之间的时间戳可能产生微小但真实的偏差。2035 年废除之后,闰秒平滑本身将变得不再必要,从而简化各云平台之间的互操作性。
一旦闰秒停止,UTC 将以固定偏移量运行于 TAI 之上(目前为 37 秒)。地球自转的变化将只反映在 UT1 中,不再影响 UTC。天文学家和某些导航系统将继续使用 UT1,但日常 IT 系统可以完全依赖 UTC 而无需任何进一步调整。
从长远来看,UTC 与太阳时(UT1)之间的差距将持续累积。按照目前地球减速的速率,差距将在 100 年后达到约一分钟,约 1000 年后达到一小时。这些变化跨越数代人缓慢展开,远超任何人能感知的速度。CGPM 的决定实质上是将长期天文对齐的问题留给后代处理,同时为我们这个时代消除了运行层面的隐患。
这篇文章对您有帮助吗?
UTC并非由一台时钟产生,而是由全球80多个研究机构的数据经巴黎BIPM加权平均生成。本文讲解TAI、闰秒决策、从卫星到NTP的分发渠道,以及即将到来的秒的重新定义。
从铯喷泉钟到光晶格钟,原子计时定义了秒,并支撑着 GPS、金融交易和物理实验。本文解释其原理、已达到的精度水平,以及为什么超稳定时钟对隐形基础设施至关重要。
以本地时间配置的 cron 任务在夏令时切换期间会静默地重复执行或跳过。本文详解其故障模式,介绍以 UTC 运行调度的方案、Kubernetes CronJob 的 timeZone 字段,以及云调度器如何处理同样的问题。