4

In 2012, there was a question here on SO, whether .NET's DateTime are capable of recognizing leap seconds. [1] The answer was no.

The documentation is still explicitly stating that it is not. [2]

However, Windows Server 2019 and the Windows 10 October 2018 update made Windows itself leap second aware. [3]

This begs the question: is .NET inherently leap second aware now? More specifically: can I make my DateTime structures leap second aware as well, by somehow opting in?

Edit:

From a MS Word document titled "Quest: Write a Leap Second Aware Application on Windows" [4] (emphasis by me):

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.)

And from [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.

So it seems that .NET will be leap second aware some time in the future. Thus I will not post this as the solution.

[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 (MS Word)

[5] https://aka.ms/ITPro-LeapSecond (MS Word)

Community
  • 1
  • 1
  • Paging @JonSkeet... – Ian Kemp May 03 '19 at 06:35
  • 1
    What exactly do you mean by "leap second aware"? You still can't initialize a DateTime struct with 60 seconds: https://www.ideone.com/mrublk, https://learn.microsoft.com/en-us/dotnet/api/system.datetime.-ctor?view=netframework-4.8#System_DateTime__ctor_System_Int32_System_Int32_System_Int32_System_Int32_System_Int32_System_Int32_ – CodeCaster May 03 '19 at 08:10
  • Beyond the considerable registry hacking to turn this on, an app needs to call either the GetSystemTime() or GetLocalTime() winapi functions to observe the 60 seconds value. The only functions that crack the system clock into hh/mm/ss. Neither the CLR nor the framework use those functions, you'd have to use pinvoke. – Hans Passant May 03 '19 at 09:53
  • @HansPassant, it seems so, but obviously, there is something going on behind the scenes, see my edit. –  May 03 '19 at 13:40
  • @IanKemp, is/was Jon Skeet involved in making Windows leap second aware? –  May 03 '19 at 13:42
  • The .NET behavior is not in any way special. It has always worked that way for any kind of framework and is indistinguishable from what happens when the machine gets a time server update that corrects the clock by one second. Backgrounder [is here](https://stackoverflow.com/a/29164665/17034). The probable motivation is to make Windows more compatible with Unix code, the kind that must deal with leap seconds by itself. Seems to me you are trying too hard to find a problem. – Hans Passant May 03 '19 at 13:49
  • 1
    @Herb Jon Skeet knows a thing or two about dates and times, having ported Joda Time to Noda Time. See https://codeblog.jonskeet.uk/category/nodatime/. – CodeCaster May 03 '19 at 13:52
  • @HansPassant, much as I respect you, I believe your backgrounder is not having it correct: with Win 10, there is no time smearing, but time halting for a whole second. –  May 05 '19 at 15:39

2 Answers2

3

[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

Source: https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment-434440807

Tarek Sayed - MSFT
  • 106
  • 4
2

Expanding on the accepted answer by providing some more details possibly of interest.

While UTC is aware of the occasional (and disputed [1]) insertion of a leap second, .NET's DateTime structure prior to Windows Server 2019 and the Windows 10 October 2018 update is not,[2] because Windows itself was neither.[3][4]

But even with Window's kernel now being leap seconds aware, applications still are not, unless specific action is taken.[5] The .NET framework itself does not support leap seconds yet.[6]

However, Windows systems update their time via NTP (using UTC), which is leap seconds aware.[7] This could cause time discontinuities with Windows systems, because the Windows Time service working as a NTP client could wish to synchronize the system's time immediately upon next synchronization somewhen after the leap second, potentially causing the clock to jump backwards 1 second.[8]

Of course, the occurrence of a negative time value could (and on Linux systems did [9][10]) result in undesirable or unpredictable behavior, which is why Windows won't let this happen.

When calling the DateTime.Now methods, the leap second aware Windows API function GetSystemTimeAsFileTime is called. When obtaining the leap second 23:59:60 UTC, it is treated as a second occurence of 23:59:59 UTC without re-counting the 100 ns ticks, but keeping all 10 million ticks of that second at the maximum tick count possible instead, i.e., the timekeeping is effectively halted for a second.[11]

Note, that entering 23:59:60 as a time in a DateTime structure causes .Net to perform checks as per the so far occured leap seconds. If it was one indeed, it will be accepted (but converted to 23:59:59).[11]

[1] International Earth Rotation and Reference Systems Service (IERS); Coordinated Universal Time (UTC) to retain "leap second" – https://www.iers.org/SharedDocs/Publikationen/EN/IERS/Publications/messages/IERS_Message_No_282.html

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

[3] Microsoft; How the Windows Time service treats a leap second – https://support.microsoft.com/en-us/help/909614/how-the-windows-time-service-treats-a-leap-second

[4] Microsoft; Support for the leap second – https://support.microsoft.com/en-us/help/2722715/support-for-the-leap-second

[5] Microsoft; Leap Second Validation for Developers – https://aka.ms/Dev-LeapSecond

[6] Microsoft; Leap Second Validation for IT Pros – https://aka.ms/ITPro-LeapSecond

[7] D. Mills (University of Delaware); Leap Second Processing – https://www.eecis.udel.edu/~mills/ntp/html/leap.html

[8] Microsoft; How the Windows Time service treats a leap second – https://support.microsoft.com/en-us/help/909614/how-the-windows-time-service-treats-a-leap-second

[9] Wired; 'Leap Second' Bug Wreaks Havoc Across Web – https://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-with-java-linux/

[10] /root.in; Leap second bug in linux kernel – https://www.slashroot.in/leap-second-bug-linux-kernel

[11] Github; Leap second statement is confusing – https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment-434440807