DateTime vs. DateTimeOffset in .NET

DateTime was the first type the .NET Framework had to represent times. Unfortunately, it very quickly became apparent that DateTime had a design flaw: the times are not unique.
Therefore, with .NET 2.0, DateTimeOffset was introduced very early to correct these issues.

Nevertheless DateTime has a high prevalence: and thus a huge error potential due to missing time information.
It is high time to replace DateTime with DateTimeOffset.

1. Why you should use DateTimeOffset
2. Don’t use DateTime Use DateTimeOffset
3. DateTime vs. DateTimeOffset ▪ DateTimeOffset was introduced very early with .NET 2.0 to correct design flaws of DateTime from .NET 1.0. ▪ Unlike DateTime, DateTimeOffset represents a truly instantaneous time, also known as absolute time. ▪ The use of DateTime often results in the loss of uniqueness of the exact date and time → uncorrectable consequential issues. ▪ DateTimeOffset values are much more common than those for DateTime values. As a result, DateTimeOffset should be the default date and time type in all you .NET Apps and Libs. https://docs.microsoft.com/en-us/dotnet/standard/datetime/choosing-between-datetime
4. https://docs.microsoft.com/en-us/dotnet/standard/datetime/choosing-between-datetime Stop using DateTime, wherever possible! Use DateTimeOffset
5. Respect ISO 8601 ISO 8601 represents an international standard and covers all date- and time related information. Use Extension Methods for easier and general access.
6. New .NET 6 Types DateOnly and TimeOnly ▪ Long-awaited Types will be part of .NET 6 (starting preview 4) ▪ They only represent a date or a time without any time zone relation ▪ Work well with existing implementations like in databases ▪ Use them for stuff like recurring jobs, alarms (e.g., every morning 08:00), use cases where you don’t need absolute time DON’T USE THEM FOR ABSOLUTE TIME INFORMATION