由於在6月30日的23:59:59之後將會插入一個extra second，因此本週末時間較長。在SQL Server 2008中存儲閏秒
我們有一個系統可以全天候記錄大量數據，而其中一項業務規則是，在同一時間內沒有兩個記錄可以記錄爲在一秒內發生。
我們使用UTC日期時間和新的datetimeoffset數據類型，但據我所知他們不會讓您在一分鐘內超過60秒。
當然，這將引發一個錯誤：
select datediff(ss, getdate(), '30-jun-2012 23:59:60')
但根據UTC神，這將是一個真正的時間。事件發生在23:59:60，但我們沒有辦法記錄這個事實。
23:59:59加上一秒鐘抵消仍將被視爲00:00:00 7月1日。
如何正確記錄數據庫中發生的事件23:59:60？
你不能，因爲SQL從Windows獲得時間，而Windows也不支持閏秒。
Windows通過從上游時間服務器獲取新時間並應用通常的調整（如果它很簡單）來應用閏秒clock drift。
通常這意味着在一段延長的時間內每秒調整幾秒。超過24小時，它將在每分鐘約1毫秒的時間內完成。
基本上，大多數應用程序只是假裝沒有這回事如閏秒。
對於大多數目的而言，這並不重要。如果你有一個重要的應用程序，操作系統不會幫助你。您還需要一些特殊的硬件來跟蹤時間，因爲操作系統通常無法將時間保持在一秒之內。默認情況下，Windows每週或更短時間同步時間，而大多數便宜的PC硬件時鐘（或者甚至是那些昂貴的服務器中的時鐘）可以在那段時間內輕鬆漂移幾秒鐘。
既然你關心確切的時間，我假設你指向pool.ntp.org或你的區域子網，並已設置w32time每天幾次同步。
請注意，通過調整下一次ntp同步的時間，您的時鐘會放慢速度，讓將來集成到您的系統中。順便說一句，當您的時鐘太遠時，它將被設置爲正確的時間，從而導致數據庫中重複項的相同問題。 MSDN：「[...調整時鐘速率...以允許它朝向正確的時間收斂。如果時間差...太大...時間服務設置本地時鐘...]（https ：//technet.microsoft.com/en-us/library/cc773013（v = ws.10）的.aspx＃w2k3tr_times_how_izcr）」 – eFloh
看來你的業務規則忽略了現實。 –
如何？記錄的事件每秒不會超過一次。我不知道你也在同一個項目上工作。 – Widor
我在開玩笑說，但現實是系統無法爲閏秒存儲時間戳，因此在閏秒期間不可能每秒記錄一個事件。業務規則要求通過傳統手段難以滿足的事情。重新思考規則，爲閏秒制定例外規定，或編寫瘋狂的一次性代碼。 –