.net - 通过 Win 10 Oct 2018 更新，Windows 可以识别闰秒。 .NET 的 DateTime 现在也是吗？

Question

2012 年，SO 上有一个问题，.NET 的 DateTime 是否能够识别闰秒。 [1] 答案是否定的。

文档仍然明确说明它不是。 [2]

但是，Windows Server 2019 和 Windows 10 October 2018 更新让 Windows 意识到了闰秒。 [3]

这引出了一个问题:.NET 现在是否天生就具有闰秒意识？更具体地说:我是否可以通过某种方式选择让我的 DateTime 结构也具有闰秒意识？

编辑:

摘自题为“任务:在 Windows 上编写一个 Leap Second Aware 应用程序”的 MS Word 文档 [4](由我强调):

Known issues: Some frameworks are known to calculate time incorrectlyafter a leap second occurs. For example, the .NET Framework uses itsown internal logic to determine what time it is. Its logic does notaccount for leap seconds. So after a leap second is introduced to theOperating System the output of “System.DateTime.Now.ToString()” willbe ahead by one second of the local system time. (We are working withthe .NET framework team on this.)

来自[5]:

Some applications are known to calculate time incorrectly by assumingthat there are always 60 seconds in a minute. Since leap seconds canchange this behavior, they will improperly record the time during thisevent. For example (at the time of writing):

.NET Framework usesits own internal logic to determine what time it is and does notaccount for leap seconds. As a result, PowerShell, which relies on the.NET Framework, will not report the 61st second (number 60) when usingGet-Date

Event Viewer: The date of the event will be incorrectlyrecorded. However, the event metadata will properly record the systemtime (showing the 60th second).

Note: These teams are working towards updating their software to usemore appropriate math when handling leap seconds.

因此，.NET 似乎在未来的某个时候会支持闰秒。因此，我不会将此作为解决方案发布。

[1] Are .Net's DateTime methods capable of recognising a Leap Second?

[2] https://learn.microsoft.com/en-us/dotnet/api/system.datetime.ticks?redirectedfrom=MSDN&view=netframework-4.8#System_DateTime_Ticks

[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 (微软字)

Answer 1

[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