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://docs.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)
[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
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://docs.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
