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?
[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)
[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