对 leap second 的支持

本文提供有关对 leap second 的Microsoft支持的信息。

原始 KB 数: 2722715

总结

本文包含有关对 leap second Microsoft 支持的信息。 第二个跃点是一秒的调整,它偶尔应用于协调世界时(UTC),以保持其一天中的时间接近平均太阳时间,或UT1。

注意

Windows Server 2019 和 Windows 10 2018 年 10 月更新确实支持平台中的跳跃秒。 但是,本文不适用于这些或更高版本的操作系统。 有关详细信息,请参阅:

详细信息

(1) Windows

关于 OS
Windows 操作系统(OS)不会单独处理 Leap second 处理。 例如,Windows OS 不支持采用以下格式的年份、月、日期和时间信息:

yyyy/mm/dd 08:59:60

因此,2012/7/1 08:59:60 按 ISO 8601 格式处理为 2012/7/1 09:00:00。

关于时间同步服务 (Windows 时间服务)
即使 Windows 时间服务从 NTP 服务器传递到托管 Windows 时间服务的服务器以及从它同步的下层客户端,Windows 时间服务也不会实现 leap 秒。 Windows 时间同步服务(W32Time)不会插入一个 leap 秒,而是继续执行通常的时间同步过程。

在上游 NTP 服务器(包括 W32time Server)上引入一个 leap 秒之后的短暂时间段内,上游 NTP 服务器与从上游 NTP 服务器同步的 W32time 客户端之间发生大约一秒的时间差。 W32time 客户端在随后从上游服务器同步时间时更正其本地时钟。

有关详细信息,请参阅以下Microsoft知识库(KB)一文:

909614 Windows 时间服务如何处理跃升秒

此外,在 Windows 时间服务中,并不总是有可能防止出现边际时间差异,例如 1 秒。 操作系统旨在处理时间变化。 可以干净地处理 Leap 第二个变体,从而允许不间断执行。 有关详细信息,请参阅以下知识库文章:

939322支持边界,为高准确度环境配置 Windows 时间服务

关于群集服务,至于群集配置,它与 OS 相同:不执行 leap 秒处理。

(2) SQL Server 2000、2005、2008、2008 R2、2012 和 2014

SQL Server 不使用时间数据来管理内部操作,例如事务。 因此,即使系统时间发生一秒偏差,因为第二个跃点,它不会影响 SQL Server 操作。 与 Windows OS 一样,SQL Server 无法独立识别 leap 秒。

请注意,日期数据类型(例如日期时间)不支持秒值达到 60 的格式,例如 2012/7/1 08:59:60。 因此,如果从支持 leap 秒的 OS 上运行的应用程序建立到 SQL Server 的连接,并且 OS 会尝试在日期数据类型的列和变量中设置第二个跃点(其中第二个值为 60 的数据),则返回错误。 有关详细信息,请参阅以下“参考信息”部分。

参考信息

[示例]当将 leap 秒作为 SQL Server 中的日期数据类型进行处理时

create table leap_second(
a int,
b datetime,
)
go
insert into [leap_second] values (1,convert(datetime,'2012/07/01 08:59:60'))
go
select convert(datetime,'2012/07/01 08:59:60')
go
select datediff(day,convert(datetime,'2012/07/01 08:59:60'),getdate())
go
declare @b datetime
set @b='2012/07/01 08:59:60'
go
declare @c time
set @c='08:59:60'
go
declare @d datetime2
set @d='2012/07/01 08:59:60'
go
declare @e datetimeoffset 
set @e='2012/07/01 08:59:60'
go

Result
消息 242、级别 16、状态 3、行 1
由于从 varchar 数据类型转换为 datetime 数据类型,该值在范围之外设置。
声明已经结束。

消息 242、级别 16、状态 3、行 1
由于从 varchar 数据类型转换为 datetime 数据类型,该值在范围之外设置。

消息 242、级别 16、状态 3、行 1
由于从 varchar 数据类型转换为 datetime 数据类型,该值在范围之外设置。

消息 242、级别 16、状态 3、第 3 行
由于从 varchar 数据类型转换为 datetime 数据类型,该值在范围之外设置。

消息 241、级别 16、状态 1、行 2
转换过程在从字符串转换为日期和时间或两者之一期间失败。

消息 241、级别 16、状态 1、行 2
转换过程在从字符串转换为日期和时间或两者之一期间失败。

消息 241、级别 16、状态 1、行 2
转换过程在从字符串转换为日期和时间或两者之一期间失败。

(3) Exchange Server 2003、2007、2010 和 2013

Exchange Server 中使用的时间包括由系统时钟测量的时间以及自服务启动以来计算为已用时间段的时间。 在使用系统时钟的处理中,Exchange 服务器无需识别 leap 秒即可运行。 另一方面(如果涉及经过的时间段),尽管一秒的差值与第二个跃点的插入发生,但即使在正常情况下也会发生这种偏差。 与 Windows OS 一样,Exchange Server 旨在处理轻微的时间变化。 因此,Exchange Server 操作不会受到影响。

除了内部操作之外,iCalendar 格式的计划还表示一种情况,在这种情况下,可以接收(从外部)添加一个跃点秒的时间值。 但是,当 Exchange Server 以 iCalendar 格式接收计划时,程序仅支持按照 RFC 5545 定义时间表示法的格式。 对于 leap 秒,秒表示法在 060 范围内受支持。 如果将大于 60 的数字指定为秒值,则会将其处理为无效格式,并且无法识别为正确的 iCalendar 格式。

在 Outlook 中,60 秒被视为 0。 因此,2012/07/01 08:59:60 变为 2012/07/01 08:59:00。 这意味着可能最多出现一分钟的偏差。 在这种情况下,接收电子邮件的顺序似乎已经偏离,但否则对操作没有影响。

有关详细信息,请参阅以下部分:

2.2.36 [RFC5545] 第 3.3.12 节时间

(4) Internet Information Services (IIS)

第二个跃点在 IIS 中不起作用。

(5) 其他

在 Windows 中运行的应用程序通常使用系统时钟。 因此,可以在不考虑 leap 秒的情况下使用它们。

但是,如果从管理时间并支持 leap 秒的应用程序访问Microsoft产品,或者从支持 leap 秒的 OS 上运行的应用程序访问,则可能会出现问题。 这是因为Microsoft产品无法识别第二个跃点。

此外,应用程序不应依赖系统时间以单调方式增加。 相反,它们应使用 GetTickCount64() 函数读取当前时钟周期计数,这是自启动以来的时间(以毫秒为单位)。