计算机

“国际地球转动服务组织”发布世界时间,于 7 月 1 日增加 1 秒,也就是“闰秒”。看似短短的 1 秒,一般人觉得可以多睡 1 秒钟,多偷懒 1 秒钟,但为了这 1 秒,你知道电脑程序、系统的管理员要花上多少功夫应战吗?

闰秒的生成

在探讨闰秒对电脑系统带来的影响之前,先来看看什么是闰秒。在“时间”的度量衡上,分为以原子钟为标准计时的“协调世界时”(Coordinated Universal Time, UTC),以及依据地球自转、公转运动,再以地球极轴运动修正的“世界时”(Universal Time 1, UT1)。前者就是世界各国依循使用的标准时间,以英国格林威治的时间为基准,台湾时间比英国格林威治快上 8 个小时,即 UTC+8。

至于这两个时间的度量衡有什么差别呢?事实上,地球自转的速度并非规律一致,而会因地质分布或其他星球引力的影响,导致时快时慢,但长远来讲会越来越慢,因此以规律的原子钟为基准记时的 UTC,会与以天文现象记时的 UT1 不同步。

为了协调两个时间,不让太阳上升到正中央、时钟却走到了午夜 12 点,这种时刻与自然节律不一致的状况发生,1972 年,国际计量大会决定在原子时与世界时差距超过 0.9 秒时,就加、减 1 秒,让 UTC 配合 UT1,而那 1 秒,也就称做为“闰秒”(Leap Second)。

自 1972 年以来,已经出现过 25 次闰秒,而且都是正闰秒,2015 年 7 月即将增加的这 1 秒,则是第 26 次。

当要增加正闰秒时,会加在第 2 天的 00:00:00 前,也就是把 23:59:59 的下 1 秒记成 23:59:60,然后才是第 2 天的 00:00:00。如果是减去负闰秒时,则将 23:59:58 的下一秒减去,直接进入第 2 天的 00:00:00。

2015 年这一次的增加正闰秒,台湾时间发生在 7 月 1 日 07:59:59 的下一秒,即 07:59:60,再来才是 08:00:00。

AWS 作法:把闰秒分散出去

对于一般人来说,闰秒的出现,就是把时钟、手表调快或调慢 1 秒钟。但对于电脑系统,由其是那些需要精准对时的 GPS、通讯设备、金融系统来说,可就得用心处理,况且闰秒的发生并没有规律,因此对应闰秒的时间调整,不会一开始就写在系统里。上一次的闰秒发生在 2012 年 6 月 30 日跨至 7 月 1 日时,结果造成 Reddit、Mozilla、RedHat、LinkedIn 等数家网站,因为网站底层软件平台无法应变这多出的 1 秒而宕机。

Amazon Web Services 服务是众多网站经营者选用的云端服务器,如何让系统的时间与 UTC 一致,是 Amazon 必须要应战的课题,而 AWS 选用的应战方法是,“不增加闰秒,但仍保持时间与 UTC 一致”。

AWS 并不打算让系统在 23:59:59 之后,加入 23:59:60 这 1 秒钟的闰秒;它采用的做法是,将这 1 秒平均摊在闰秒出现前后的 24 个小时,让每秒的秒数稍微增长一点点,最后补满 1 秒。

更仔细来说,一天有 86400 秒,闰秒即是 86400/86400,从 6 月 30 日 12:00:01 PM(中午)开始,AWS 系统的时钟每秒都会增加 1/86400 秒,每秒长度变成 1+1/86400 秒,过了 24 小时至 7 月 1 日 12:00:00 PM 时,就刚好补满 1 秒。

这样做的好处是,系统的时钟不需特别为闰秒设计一个“23:59:60”的记时,仍旧以 60 秒为 1 分钟的单位,而且除了 23:59:60 这个闰秒记时与 UTC 不同步以外,其他每秒仍与 UTC 同步。虽然在 UTC 加入闰秒之前,AWS 系统的时间会比 UTC 快一些,加入闰秒之后 AWS 系统的时间会比 UTC 慢一些,但总地来说,这些差距最多只差到 0.5 秒,不对系统构成影响。

AWS 对应闰秒的调整方式,会使得它比 UTC 快一些或慢一些,但最终会一致。

除了像 AWS 这种“把闰秒分散出去”的作法,其他应战闰秒的作法还有像 Linux Kernels 一样把 23:59:59 重复一次,以及像 Windows time servers 忽略闰秒,在闰秒增加之后再让系统时间与 UTC 同步。当然,若系统没有与任何时间同步系统连线的话,也就不会因闰秒而产生任何调整,但系统时间就比 UTC 慢了一秒。

虽然有不少应战闰秒的方式,但攸关金钱进出的股票交易市场仍对闰秒可能带给系统的影响较为敏感,甚至避开在闰秒增加时交易。台湾增加闰秒的时间股市还未开市,所以较为无感,然而芝加哥商品交易所(CME)和洲际交易所预计将 6 月 30 日夜间电子开盘时间延后,以避开闰秒。

via: technews.cn