通过 Win 10 Oct 2018 更新，Windows 可以识别闰秒。 .NET 的 DateTime 现在也是吗？
With the Win 10 Oct 2018 update, Windows is leap second aware. Is .NET's DateTime, too, now?
2012年SO上有个问题，.NET的DateTime能不能识别闰秒。 [1] 答案是否定的
文档仍然明确说明它不是。 [2]
但是，Windows Server 2019 和 Windows 2018 年 10 月 10 日更新使 Windows 本身 意识到闰秒。 [3]
这引出了一个问题：.NET 现在是否天生就具有闰秒意识？更具体地说：我可以通过某种方式选择让我的 DateTime 结构也知道闰秒吗？
编辑：
来自题为“任务：在 Windows 上编写一个 Leap Second Aware 应用程序”的 MS Word 文档[4]（我强调）：
Known issues: Some frameworks are known to calculate time incorrectly
after a leap second occurs. For example, the .NET Framework uses its
own internal logic to determine what time it is. Its logic does not
account for leap seconds. So after a leap second is introduced to the
Operating System the output of “System.DateTime.Now.ToString()” will
be ahead by one second of the local system time. (We are working with
the .NET framework team on this.)
来自 [5]：
Some applications are known to calculate time incorrectly by assuming
that there are always 60 seconds in a minute. Since leap seconds can
change this behavior, they will improperly record the time during this
event. For example (at the time of writing):
.NET Framework uses
its own internal logic to determine what time it is and does not
account for leap seconds. As a result, PowerShell, which relies on the
.NET Framework, will not report the 61st second (number 60) when using
Get-Date
Event Viewer: The date of the event will be incorrectly
recorded. However, the event metadata will properly record the system
time (showing the 60th second).
Note: These teams are working towards updating their software to use
more appropriate math when handling leap seconds.
因此，.NET 似乎在未来的某个时候会支持闰秒。因此我不会post这个作为解决方案。
[1] Are .Net's DateTime methods capable of recognising a Leap Second?
[3]https://support.microsoft.com/en-us/help/2722715/support-for-the-leap-second
[4] https://aka.ms/Dev-LeapSecond（微软字）
[5] https://aka.ms/ITPro-LeapSecond（微软字）
[H]ere is some clarification how the .NET (version 4.7.2) work on the
version of Windows that support the leap seconds (i.e. Windows 10 RS5
release):
DateTime (DT) and DateTimeOffset (DTO) are not changed in how it
stores the time units and how operate on such units. These types just
store ticks and the tick is 100 nanoseconds. When converting between
ticks and date/time parts (e.g. year month, day, hour, minute, second,
millisecond) it always assumes the minute is 60 seconds and cannot be
61 seconds. i.e. no leap seconds counted in the ticks or in the
conversion.
When calling Now property on DT and DTO, we'll end up
calling Windows API (e.g. GetSystemTimeAsFileTime).
GetSystemTimeAsFileTime has the leap seconds counted there. So, .NET
is doing extra step when running on the leap seconds enabled system to
get the exact time by calling more Windows API which can report the
system time to ensure .NET reported time is synchronized with the
system. .NET still calling GetSystemTimeAsFileTime for the sake of
getting more precise time (which is 100 nanoseconds accuracy).
In case
Windows report to us a second number 60 (which is a leap second), .NET
will assume this is the last second in that minute and use it as a
second 59 to make it work seamlessly with DT and DTO as these types
not aware of leap seconds.
If someone try to create a DT or DTO with a
leap second (60), .NET will check first by calling Windows API if this
is a valid leap second then convert it to second number 59. If it is
not valid leap second, then we'll throw exception.
.NET didn’t change
how DT and DTO work for the sake of application compatibility as we
know many users doing the same assumptions in their code that ticks
always has the minute is 60 seconds. And ticks in different system
cannot mean different time. Let me know if you have any more questions
or you need more clarification
来源：https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment-434440807
通过提供更多可能感兴趣的细节来扩展已接受的答案。
虽然 UTC 知道偶尔（和有争议的 [1]）插入闰秒，.NET 的 DateTime 结构先于 Windows Server 2019 和 Windows 10 2018 年 10 月更新不是，[2] 因为 Windows 本身都不是。[3][4]
但即使 Window 的内核现在可以识别闰秒，应用程序仍然不能识别，除非采取特定的措施。[5] .NET 框架本身还不支持闰秒。 [6]
但是，Windows 系统通过 NTP（使用 UTC）更新时间，这是闰秒感知。[7]这可能会导致 Windows 系统的时间不连续，因为作为 NTP 客户端工作的 Windows 时间服务可能希望在闰秒之后的某个时间在下一次同步时立即同步系统时间，这可能会导致时钟跳转倒退 1 秒。[8]
当然，负时间值的出现可能（在 Linux 系统上 [9][10]）会导致不良或不可预测的行为，这就是为什么 Windows 不会'不要让这发生。
调用 DateTime.Now 方法时，会调用闰秒感知 Windows API 函数 GetSystemTimeAsFileTime。当获得闰秒 23:59:60 UTC 时，它被视为 23:59:59 UTC 的第二次出现而不重新计算 100 ns 滴答声，但将那一秒的所有 1000 万滴答声保持在可能的最大滴答声计数相反，即计时实际上停止了一秒钟。[11]
请注意，在 DateTime 结构中输入 23:59:60 作为时间会导致 .Net 根据到目前为止发生的闰秒执行检查。如果它确实是一个，它将被接受（但转换为 23:59:59）。[11]
[1] 国际地球自转和参考系统服务 (IERS)；协调世界时 (UTC) 以保留 "leap second" – https://www.iers.org/SharedDocs/Publikationen/EN/IERS/Publications/messages/IERS_Message_No_282.html
[2] 微软； DateTime.Ticks 属性 – https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?redirectedfrom=MSDN&view=netframework-4.8#System_DateTime_Ticks
[3] 微软； Windows 时间服务如何处理闰秒 – https://support.microsoft.com/en-us/help/909614/how-the-windows-time-service-treats-a-leap-second
[4] 微软；支持闰秒 – https://support.microsoft.com/en-us/help/2722715/support-for-the-leap-second
[5] 微软；开发人员的闰秒验证 – https://aka.ms/Dev-LeapSecond
[6] 微软；面向 IT 专业人员的闰秒验证 – https://aka.ms/ITPro-LeapSecond
[7] D. Mills（特拉华大学）；闰秒处理 – https://www.eecis.udel.edu/~mills/ntp/html/leap.html
[8] 微软； Windows 时间服务如何处理闰秒 – https://support.microsoft.com/en-us/help/909614/how-the-windows-time-service-treats-a-leap-second
[9] 有线； 'Leap Second' 漏洞在网络上造成严重破坏 – https://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-with-java-linux/
[10] /root.in; linux 内核中的闰秒错误 – https://www.slashroot.in/leap-second-bug-linux-kernel
[11] Github;闰秒声明令人困惑 – https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment-434440807
2012年SO上有个问题，.NET的DateTime能不能识别闰秒。 [1] 答案是否定的
文档仍然明确说明它不是。 [2]
但是，Windows Server 2019 和 Windows 2018 年 10 月 10 日更新使 Windows 本身 意识到闰秒。 [3]
这引出了一个问题：.NET 现在是否天生就具有闰秒意识？更具体地说：我可以通过某种方式选择让我的 DateTime 结构也知道闰秒吗？
编辑：
来自题为“任务：在 Windows 上编写一个 Leap Second Aware 应用程序”的 MS Word 文档[4]（我强调）：
Known issues: Some frameworks are known to calculate time incorrectly after a leap second occurs. For example, the .NET Framework uses its own internal logic to determine what time it is. Its logic does not account for leap seconds. So after a leap second is introduced to the Operating System the output of “System.DateTime.Now.ToString()” will be ahead by one second of the local system time. (We are working with the .NET framework team on this.)
来自 [5]：
Some applications are known to calculate time incorrectly by assuming that there are always 60 seconds in a minute. Since leap seconds can change this behavior, they will improperly record the time during this event. For example (at the time of writing):
.NET Framework uses its own internal logic to determine what time it is and does not account for leap seconds. As a result, PowerShell, which relies on the .NET Framework, will not report the 61st second (number 60) when using Get-Date
Event Viewer: The date of the event will be incorrectly recorded. However, the event metadata will properly record the system time (showing the 60th second).
Note: These teams are working towards updating their software to use more appropriate math when handling leap seconds.
因此，.NET 似乎在未来的某个时候会支持闰秒。因此我不会post这个作为解决方案。
[1] Are .Net's DateTime methods capable of recognising a Leap Second?
[3]https://support.microsoft.com/en-us/help/2722715/support-for-the-leap-second
[4] https://aka.ms/Dev-LeapSecond（微软字）
[5] https://aka.ms/ITPro-LeapSecond（微软字）
[H]ere is some clarification how the .NET (version 4.7.2) work on the version of Windows that support the leap seconds (i.e. Windows 10 RS5 release):
DateTime (DT) and DateTimeOffset (DTO) are not changed in how it stores the time units and how operate on such units. These types just store ticks and the tick is 100 nanoseconds. When converting between ticks and date/time parts (e.g. year month, day, hour, minute, second, millisecond) it always assumes the minute is 60 seconds and cannot be 61 seconds. i.e. no leap seconds counted in the ticks or in the conversion.
When calling Now property on DT and DTO, we'll end up calling Windows API (e.g. GetSystemTimeAsFileTime). GetSystemTimeAsFileTime has the leap seconds counted there. So, .NET is doing extra step when running on the leap seconds enabled system to get the exact time by calling more Windows API which can report the system time to ensure .NET reported time is synchronized with the system. .NET still calling GetSystemTimeAsFileTime for the sake of getting more precise time (which is 100 nanoseconds accuracy).
In case Windows report to us a second number 60 (which is a leap second), .NET will assume this is the last second in that minute and use it as a second 59 to make it work seamlessly with DT and DTO as these types not aware of leap seconds.
If someone try to create a DT or DTO with a leap second (60), .NET will check first by calling Windows API if this is a valid leap second then convert it to second number 59. If it is not valid leap second, then we'll throw exception.
.NET didn’t change how DT and DTO work for the sake of application compatibility as we know many users doing the same assumptions in their code that ticks always has the minute is 60 seconds. And ticks in different system cannot mean different time. Let me know if you have any more questions or you need more clarification
来源：https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment-434440807
通过提供更多可能感兴趣的细节来扩展已接受的答案。
虽然 UTC 知道偶尔（和有争议的 [1]）插入闰秒，.NET 的 DateTime 结构先于 Windows Server 2019 和 Windows 10 2018 年 10 月更新不是，[2] 因为 Windows 本身都不是。[3][4]
但即使 Window 的内核现在可以识别闰秒，应用程序仍然不能识别，除非采取特定的措施。[5] .NET 框架本身还不支持闰秒。 [6]
但是，Windows 系统通过 NTP（使用 UTC）更新时间，这是闰秒感知。[7]这可能会导致 Windows 系统的时间不连续，因为作为 NTP 客户端工作的 Windows 时间服务可能希望在闰秒之后的某个时间在下一次同步时立即同步系统时间，这可能会导致时钟跳转倒退 1 秒。[8]
当然，负时间值的出现可能（在 Linux 系统上 [9][10]）会导致不良或不可预测的行为，这就是为什么 Windows 不会'不要让这发生。
调用 DateTime.Now 方法时，会调用闰秒感知 Windows API 函数 GetSystemTimeAsFileTime。当获得闰秒 23:59:60 UTC 时，它被视为 23:59:59 UTC 的第二次出现而不重新计算 100 ns 滴答声，但将那一秒的所有 1000 万滴答声保持在可能的最大滴答声计数相反，即计时实际上停止了一秒钟。[11]
请注意，在 DateTime 结构中输入 23:59:60 作为时间会导致 .Net 根据到目前为止发生的闰秒执行检查。如果它确实是一个，它将被接受（但转换为 23:59:59）。[11]
[1] 国际地球自转和参考系统服务 (IERS)；协调世界时 (UTC) 以保留 "leap second" – https://www.iers.org/SharedDocs/Publikationen/EN/IERS/Publications/messages/IERS_Message_No_282.html
[2] 微软； DateTime.Ticks 属性 – https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?redirectedfrom=MSDN&view=netframework-4.8#System_DateTime_Ticks
[3] 微软； Windows 时间服务如何处理闰秒 – https://support.microsoft.com/en-us/help/909614/how-the-windows-time-service-treats-a-leap-second
[4] 微软；支持闰秒 – https://support.microsoft.com/en-us/help/2722715/support-for-the-leap-second
[5] 微软；开发人员的闰秒验证 – https://aka.ms/Dev-LeapSecond
[6] 微软；面向 IT 专业人员的闰秒验证 – https://aka.ms/ITPro-LeapSecond
[7] D. Mills（特拉华大学）；闰秒处理 – https://www.eecis.udel.edu/~mills/ntp/html/leap.html
[8] 微软； Windows 时间服务如何处理闰秒 – https://support.microsoft.com/en-us/help/909614/how-the-windows-time-service-treats-a-leap-second
[9] 有线； 'Leap Second' 漏洞在网络上造成严重破坏 – https://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-with-java-linux/
[10] /root.in; linux 内核中的闰秒错误 – https://www.slashroot.in/leap-second-bug-linux-kernel
[11] Github;闰秒声明令人困惑 – https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment-434440807