unixtimestamp不包括闰秒是福还是祸？
Posted: 2023-11-12T11:44:31+00:00
unixtimestamp不包括闰秒是福还是祸？
最近有一个项目中要用到时间戳，结果就碰到了闰秒问题。
因为unixtimestamp的规定里闰秒是不会被写入进来的，这就造成了一个很尴尬的问题。
硬件的时钟是会一直产生时钟信号的，机器上的时间码会据此来+1，但这仅仅是一个数字，并不会理会所加的这一秒是不是闰秒。这本身非常完美并没有问题，可以在任何设备上正确的工作。
但问题是到了unixtimestamp这里就需要从这个时间码里减去那一秒，这就很奇葩了,比如：
TAI (1 January 1999) UTC (31 December 1998 to 1 January 1999) Unix time
1999-01-01T00:00:29.75 1998-12-31T23:59:58.75 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 915148800.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915148800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915148800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 915148801.25
而且，这样也造成了很多网络中依赖 unixtimestamp 进行同步的设备，在 915148800.75 后面到达的数据包的时间戳是 915148800.00 这样一个反而比 915148800.75 更小的数值，程序岂不乱套了？！！
换句话说，unixtimestamp绑定了UTC时间线。
这样的好处就是在转换成人类可读时间时比较方便，不需要再为闰秒做单独的计算工作。但是话说回来，在转换时做的那计算工作，对于现在的计算设备来说叫个事儿吗?
反而是这样做的坏处更让人担忧。时间戳的混乱让很多科技公司头疼不已。
我的提议是将unixtimestamp与UTC时间脱离，而采用TAI(國際原子時)。这样就能使unixtimestamp成为一个线性的时间戳，网络上的各设备间的同步和协作都不会出现"时间倒流"的情况，而引起程序抛弃掉数据包。
这时将unixtimestamp时只需从UTC的发布者国际地球自转和参考系服务（International Earth Rotation and Reference Systems Service）那里读取一个偏差值并相应的做加减运算后，即可重新使用现在的代码进行转换了。
我相当不建议与国际地球自转和参考系服务（International Earth Rotation and Reference Systems Service）谈什么废除闰秒的话题，因为闰秒的存在是为了转换成人类可读模式并与历法对应的，而且仅对地球上生活的人类有意义，而这些对于计算机和网络系统并没有意义。当然，如果有一天人类扩展了我们这个物种的生存空间，也在其他天体上建立的居住区，那么UTC时间也对在那里生活的人们没有任何意义!(除了给身处地球上的亲朋好友打电话时确认一下对方是不是处在休息时间外。)
最近有一个项目中要用到时间戳，结果就碰到了闰秒问题。
因为unixtimestamp的规定里闰秒是不会被写入进来的，这就造成了一个很尴尬的问题。
硬件的时钟是会一直产生时钟信号的，机器上的时间码会据此来+1，但这仅仅是一个数字，并不会理会所加的这一秒是不是闰秒。这本身非常完美并没有问题，可以在任何设备上正确的工作。
但问题是到了unixtimestamp这里就需要从这个时间码里减去那一秒，这就很奇葩了,比如：
TAI (1 January 1999) UTC (31 December 1998 to 1 January 1999) Unix time
1999-01-01T00:00:29.75 1998-12-31T23:59:58.75 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 915148800.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915148800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915148800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 915148801.25
而且，这样也造成了很多网络中依赖 unixtimestamp 进行同步的设备，在 915148800.75 后面到达的数据包的时间戳是 915148800.00 这样一个反而比 915148800.75 更小的数值，程序岂不乱套了？！！
换句话说，unixtimestamp绑定了UTC时间线。
这样的好处就是在转换成人类可读时间时比较方便，不需要再为闰秒做单独的计算工作。但是话说回来，在转换时做的那计算工作，对于现在的计算设备来说叫个事儿吗?
反而是这样做的坏处更让人担忧。时间戳的混乱让很多科技公司头疼不已。
我的提议是将unixtimestamp与UTC时间脱离，而采用TAI(國際原子時)。这样就能使unixtimestamp成为一个线性的时间戳，网络上的各设备间的同步和协作都不会出现"时间倒流"的情况，而引起程序抛弃掉数据包。
这时将unixtimestamp时只需从UTC的发布者国际地球自转和参考系服务（International Earth Rotation and Reference Systems Service）那里读取一个偏差值并相应的做加减运算后，即可重新使用现在的代码进行转换了。
我相当不建议与国际地球自转和参考系服务（International Earth Rotation and Reference Systems Service）谈什么废除闰秒的话题，因为闰秒的存在是为了转换成人类可读模式并与历法对应的，而且仅对地球上生活的人类有意义，而这些对于计算机和网络系统并没有意义。当然，如果有一天人类扩展了我们这个物种的生存空间，也在其他天体上建立的居住区，那么UTC时间也对在那里生活的人们没有任何意义!(除了给身处地球上的亲朋好友打电话时确认一下对方是不是处在休息时间外。)