为什么程序员可以处理闰年，但处理不了闰秒？
如题。
计算机处理时间实际上是一个计数器，假设以秒为单位，需要人为规定一个0时刻，即1970/1/1 0:0 GMT+0:00。

后续的时钟就是一个不断增加的整数，例如：

31507200 = 1971-1-1 0:0:0 GMT+8:00  936838800 = 1999-9-9 9:00 GMT+8:00  1672531200 = 2023-1-1 0:00 GMT+0:00

计算机内部有电池来维持一个时钟，但时间一长肯定不准，因此，操作系统定期从互联网时钟服务器同步，如果电子设备有GPS，也可以直接从GPS拿到时钟。

计算机显示的时间实际上是根据这个整数时钟进行转换，根据设定的时区变成年月日时分秒。如果不考虑闰秒，则转换规则相当简单，比如一小时3600秒，一天24小时，则：

1672531200 秒 = 464592 小时 = 19358 天，从1970-1-1加上这么多天就能计算1672531200的日期。

上述转换是基于闰年的规则转换的，如果涉及到夏令时则需要根据夏令时规则转换。注意夏令时各国不同，但无论多复杂，它只是一个规则，你把规则写明白，就总能转换出正确的本地时间。

注意到夏令时规则不是一个简单的规则，它是会变的，比如某个国家宣布明年取消夏令时，后年恢复夏令时，因此，需要一个数据库来维护这些规则，包括所有历史改动。如果某个程序未能及时从IANA更新数据库，将来转换的日期时间就可能不对。

处理润秒也一样，比如1972-6-30 23:59:59插入了一个润秒，那么要正确处理它：

78796799 = 1972-6-30 23:59:59 GMT+0  78796800 = 1972-7-1 0:0:0 GMT+0  78796801 = 1972-7-1 0:0:0 GMT+0

也就是两个整数会转换出同一个时间，因此，大部分计算机程序根本没有处理润秒。要处理润秒，就必须把每次规则变化及时更新，但IERS这个组织宣布要加一个润秒时，仅给了不到6个月的时间，如果要保证能正确处理润秒，全世界的计算机包括各种车机、物联网芯片必须在6个月内更新规则，显然是不可能的。

所以目前计算机的做法并不是真的让78796800和78796801都转换成相同的日期时间，而是在计数到78796800时，下一个计数还是78796800，再下一个计数才是78796801，这样就保证后续程序能正常转换出日期时间。

但这个暂停计数1秒的操作非常危险（减1秒更危险，好在润秒还没减过），而且每次加减润秒都要改程序，一不小心就可能造成大面积宕机，所以大家决定2035年取消润秒。