由于闰秒，这个夜晚会更长：https : //en.wikipedia.org/wiki/Leap_second
在我的情况下，我的影响很小，我什至不知道我是否会收到一些奇怪的数据，比如20150630 23:59:60。但是我有来自 windows、linux 和其他系统的监控系统。在最坏的情况下，我将丢失一秒钟的数据。
我在 postgresql 和 SQL Server 中测试了这个奇怪数据的转换。这些是我的结果：
Postgresql 中的这个选择：
SELECT '20150630 23:59:60.001 UTC'::timestamptz;
返回：2015-07-01 02:00:00.001+02
我有相同的结果：
SELECT '20150701 00:00:00.001 UTC'::timestamptz;
我认为这在关键系统中可能很危险，因为如果这些数据由客户端处理，数据可能会以错误的顺序存储，从而为合法数据增加一秒钟。
在 sql server 中，如果我尝试：
SELECT CAST('20150630 23:59:60' AS datetime)
它给了我一个转换错误。所以在 sql server 中是不可能存储这些数据的。
一个给我一个错误，另一个只是添加一秒钟。我不喜欢两者，因为不可能在闰秒中存储事件。
两者都是最新的系统。SQL Server 在 windows 2012 机器上是 2014。Postgresql 在 redhat 机器上是 9.3（不是那么更新，我认为是 6.2）。
如果有人要我存储这些数据怎么办？我读了这个和一些解决方法：https : //stackoverflow.com/questions/19751115/leap-second-handling-in-database
有没有人遇到过这个问题？我的意思是，就我而言，这只是一个理论问题，不是真正的问题（所以如果你不喜欢理论问题，请不要浪费时间）
编辑： 在 Oracle 11.2 中测试，返回错误：
ORA-01852: 秒必须在 0 到 59 之间 01852. 00000 - “秒必须在 0 到 …