use*_*r_0 5 postgresql sql-server datetime
由于闰秒，这个夜晚会更长：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 到 59 之间”
小智 5
这是我在2012 年 1 月的pgsql邮件列表中找到的 PostgreSQL 日期处理的描述：
据我所知，该文档正在讨论超出 Postgres 范围的问题。当您告诉我们时间戳值为 '2012-01-30 21:13:28.097017-05' 时，这就是我们存储的内容 --- 无论您的意思是使用 TAI、UTC、UT1 还是我们不关心的任何内容。如果您随后要求该日期加上一天，我们将告诉您“2012-01-31 21:13:28.097017-05”。我们确实了解民用时区和夏令时转换，并将为这些调整这些答案，但不了解闰秒。 用户对闰秒感知日期算法的需求很少，将此类算法推向未来的困难意味着我们不可能尝试支持它。[强调我的]
正如Daniel Vérité在评论中提到的，这里的错误不是 PostgreSQL 不能存储闰秒——它可以——而是它无法将它们与下一秒区分开来，并且不能进行涉及闰秒的数学运算.
此外，正如dbafromthecold指出的那样，某些操作系统根本不会报告闰秒，例如Windows 时间服务如何处理闰秒。另一个例子是谷歌的服务，它应用了闰秒，在闰秒之前稍微加快了服务器时钟，以便跳过闰秒而不会比UTC时间提前太多。
所以：看起来大多数服务都很好，在闰秒左右可能会出现一秒的错误。如果您需要更准确的闰秒，AFAICT 您将需要实现自己的基于 UTC 的时钟时间。