传统日期的局限

人类在对时间的测定上存在一个进化的过程，最早通过观察天体的自转与公转来确定时间，比如地球自转一周为一天，月球公转一周为一月，地球公转一周为一年。

我们先考虑天和年，他们之间就像数学一样存在一个粗糙的进制方案——365.25天为1年。这种进制就像十进制数一样可以有效压缩日期的长度，比如我们可以记某某王朝存在了 300年，而不是 109575 天。

而说他粗糙是因为进制不是整数，这在使用上多有不便，没人喜欢在大白天突然过年吧。因此制定历法(公历)的人做出妥协：允许计时出现不超过 1 天的偏差，以实现整数进制，即 365天进一年。当累计偏差达到一天时在 2 月最后一天之后再加一个闰日。我们通常管这样的年叫做闰年。

此时，天是一个确定的时间单位，而年不是了，因为一年可能有 365 天也可能有 366 天。

作为公立的格里历在闰日的规则上更精确一些，可参考 wiki: 格里曆

以格林尼治午夜为 0 点，以观察太阳为手段计时的标准叫做 世界时(UT)。此时的秒定义为一天的 1 / 86400。

另一套计时标准

后来人们发现靠天文观测来计时不是那么准，尤其地球自转和公转的速度居然不是恒定的。于是在 1967 年人们重新定义了秒，把它从世界时一天的 1/86400 改为了

铯133原子基态的两个超精细能级间跃迁对应辐射的9,192,631,770个周期的持续时间

铯原子钟 对秒的重新定义带来了一种新的计时标准——国际原子时(TAI)，同时也带来了像 年 和 日 之间“粗糙进制”的问题：现在世界时的一天也不是标准的 86400 秒了。国际原子时从 1958年初开始计时，到 2016 年 11月已经比世界时快了 37s。(地球转的慢了)

UTC

现在电信业遇到了一个麻烦，本身他们需要使用原子钟计时，但又不得不服从世界时，毕竟只要人类还生活在地球上，时间就都要向太阳对齐。人们决定再定义一个时间，叫做 UTC，比世界时的 UT 多了一个 Coordinated，其协调的就是原子时和世界时之间的差距。

协调的方案就像闰日一样，人们选择了闰秒。人们把 UTC 1972-01-01 00:00:00 向国际原子时的 00:00:10 做了一次对齐(原子时是不闰秒的)，然后以原子秒为基础计时，同时监测与世界时的差距，适时闰 1s 或 -1s。一般闰秒的时刻选择在6月的最后一秒或12月的最后一秒。

因为原子秒的长度定义本身就参考了上百年观测的平均太阳日时间，所以这个误差其实相当低，从1972年到现在总共才闰了 27 次，且全部是 +1s。即最近地球转的比过去慢。(注意闰秒其实是随机而不可预测的，最近几十年转的慢，也许过几年就转得快了，到时候就要 -1s)

对于 UTC 的时间是哪个时区的问题，因为它总是向世界时对齐，而世界时是格林尼治时间，所以 UTC 也就是向格林尼治时间对齐。

UNIX 时间

UNIX 时间是以 UTC 时间 1970-01-01T00:00:00 为原点到现在的秒数偏移量。但因为编程的问题，它不考虑闰秒。所以它只是在跳秒的时刻上与原子时同步，而累计的秒数其实是世界时的秒数。

对于程序来说，因为闰秒的不规律性，如果要计算当前到 1970-01-01T00:00:00 的原子秒数，就需要额外存储每一次闰秒的记录。又因为人们日常需求中其实并不关心闰秒，使用原子秒记录反而会产生很多麻烦，所以就这么用了。

闰秒带来的时刻问题，比如有的系统会产生 23:59:60 这样的时刻，或者有的系统会走两次 23:59:59，就需要用户自己去处理了。而一般情形的编程下，可以认为 UNIX 时间与 UTC 时间是等价的。UTC 闰秒在计算机里也通常会被舍弃，不然的话每次计算时间还要依赖 ntp 服务器这是不现实的。即在 Python 里：

>>> (datetime.utcnow() - datetime.utcfromtimestamp(0)).total_seconds() == time.time()

>>> True

而在现实中上式不等。到现在为止，应该有 27s 的差距。

转载至链接:https://my.oschina.net/lionets/blog/1923075