关键是现在数据库里面存的时间的精度都是秒以下了,
而且,很显然的这个什么23:59:60这个时间是不存在的。
SQL Server的datetime2类型默认精度是7,也就是可以精确到0.0000001秒。
我们假设这一秒钟产生了1000条记录,那么这1000条记录存的时间应该是什么?
如果服务器时间没有对时,那么这1000条记录就会存到第二天的00:00:00.000000-00:00:01.0000000这个时间段里面,
然后过了这一秒后,时间应该跳到了00:00:01.0000000这个时间点了,结果这个时候服务器对时了,对时后发现现在还是00:00:00.0000000这个时间。
这样我们就会产生一堆超出当前时间的数据,譬如说00:00:00.0305742这种时间,这种数据事实上是上一秒钟产生的,但是我们的服务器不知道啊,我们的服务器只知道现在还是00:00:00.000000,这样一来记录的时间就会发生混乱。
最显而易见的就是自增标识字段和创建时间字段的排序可能会存在不等价的情况。
或者我们做统计数据,为啥这一秒的流量暴增两倍?
又或者我们按照时间戳增量更新数据,会不会把时间戳更新到了“未来”而导致数据丢失?
再比如我们记录轨迹,等等,这个数据为啥在这一秒钟呈现上下跳的情况?
很显然我们好吃懒做的程序员是不会考虑这种根本不可能发生的情况的,结果就是,,,,
===================================================================
我也是哔—了狗了,问题问的是为什么会有影响,那么影响的确是存在的,有可能出现在这几个方面。然后一群知乎政治正确的答案就来了,什么影响根本不大,最高票在瞎扯等等。
扯啥呢?
影响不大是不假,你家服务器一天的数据量连一万条都没有,有毛影响,你家服务器一天能漂移个一两秒,而某家的服务器一天数据量是几亿的级别,服务器一年对一次时都能保证没漂移。说的根本就不是一回事儿好不!
还有扯什么人为增加一个小时的,谁服务器里面存的是本地时间(local datetime)啊?
闰秒指的就是协调世界时(UTC)的调整,UTC时间是没有什么夏令时、时区等等一堆乱七八糟的标准时,所以闰秒才会带来问题。
其实要解决问题也跟简单,就是不要UTC时间就可以了,反正几年才差一秒根本无所谓的事情,其实大型系统都有自己的中心对时服务器,不要和UTC同步即可(或者同步但去除UTC闰秒误差)。
取消闰秒的呼声和放弃UTC时间的也不鲜见。
因为闰秒的唯一意义就是避免在几万年后UTC时间的正午12:00不是太阳直射0度经度线的时间,而这一点其实大家都不care,所以干脆就放弃UTC吧也挺好。
一秒钟产生的数据不超过两位数的,根本不用考虑这种问题,也随便你服务器漂移几十秒都可以,但是一秒钟数据几万,分布在几千台服务器的系统,时间漂移的耐受度就低得多。
没见过不代表没有。