Problem
We now have a standard approach of dealing with.NET DateTimes in a TimeZone aware manner: anytime we make a DateTime, we do it in UTC (for example, using DateTime.UtcNow), and whenever we show one, we convert back to the user’s local time.
That’s OK, however I’ve been reading about DateTimeOffset and how it stores local and UTC time in the object. So, in comparison to what we’ve been doing, what are the benefits of utilizing DateTimeOffset?
Asked by David Reis
Solution #1
DateTimeOffset is an immediate time representation (also known as absolute time). That is, I’m referring to a point in time that is universal for everyone (not accounting for leap seconds, or the relativistic effects of time dilation). A DateTime can also be used to represent instantaneous time. DateTimeKind.Utc is the kind.
Calendar time (also known as civil time) is a place on someone’s calendar, and there are many different calendars around the world. These calendars are referred to as time zones. A DateTime is used to denote calendar time. DateTimeKind is the type. DateTimeKind or unspecified Local. Moreover. Local is only useful in cases when you have a general idea of where the computer that will be using the result is located. (Take, for instance, a user’s workstation.)
So, why use DateTimeOffset rather than a UTC DateTime? It’s all about how you look at things. As an example, let’s say we’re photographers.
Assume you’re standing on a calendar timeline, pointing your camera at a person on the live timeline in front of you. You align your camera according to the rules of your timezone, which change on a regular basis due to changes in the legal definition of your time zone, such as daylight saving time. (Your camera is wobbly because you don’t have a steady hand.)
The individual in the snapshot would be able to observe the angle from which your camera was taken. If others were shooting photographs, they could be from various perspectives. This is what the DateTimeOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOffsetOff
So, if your camera is labeled “Eastern Time,” you’ll be pointing from -5 at times and -4 at other times. There are cameras pointing at the same instantaneous timeline from various angles all over the world, each labeled differently. Because some of them are adjacent to (or on top of) each other, knowing the offset alone isn’t enough to figure out which timezone the time belongs to.
What about UTC, for example? It is, after all, the only camera that is guaranteed to have a steady hand. It’s mounted on a tripod and firmly planted in the ground. It’s not going away anytime soon. Its perspective angle is known as the zero offset.
So, what do we learn from this analogy? It includes some easy-to-follow guidelines. –
Here are a few more details regarding DateTimeOffset that support this example, as well as some pointers on how to keep it straight:
Shameless Plug:
Because so many people have told me how useful this comparison is, I incorporated it in my Pluralsight course, Date and Time Fundamentals. In the second module, “Context Matters,” in the segment titled “Calendar Time vs. Instantaneous Time,” you’ll get a step-by-step breakdown of the camera example.
Answered by Matt Johnson-Pint
Solution #2
From Microsoft:
source: MSDN article “Choosing Between DateTime, DateTimeOffset, TimeSpan, and TimeZoneInfo.”
Because our program deals with specific points in time (e.g. when a record was created/updated), we use DateTimeOffset for almost everything. On a side note, DATETIMEOFFSET is also used in SQL Server 2008.
DateTime, in my opinion, is beneficial when dealing with dates exclusively, times only, or both in a generic manner. If you want an alarm to go off every day at 7 a.m., for example, you could store it in a DateTime with a DateTimeKind of Unspecified because you want it to go off at 7 a.m. regardless of DST. DateTimeOffset, on the other hand, is used to indicate the history of alarm occurrences.
When combining DateTimeOffset and DateTime, use caution, especially when assigning and comparing the two types. Also, only compare DateTime objects of the same DateTimeKind because DateTime compares without taking into account the timezone offset.
Answered by Clay
Solution #3
DateTime can only store two different times: the local time and UTC. Which is indicated by the Kind property.
DateTimeOffset takes this a step further by allowing you to store local times from anywhere on the planet. It also keeps track of the time difference between that local time and UTC. Note that you can’t achieve this with DateTime unless you add an extra member to your class to store the UTC offset. Alternatively, only work with UTC. Which, by the way, is a fantastic idea.
Answered by Hans Passant
Solution #4
DateTimeOffset is useful in a couple of situations. When dealing with repeating occurrences and daylight savings time, for example. Let’s pretend I want to set an alarm at 9 a.m. every day. When daylight savings time is in effect, the alarm will go off at a different time if I apply the “save as UTC, display as local time” rule.
There are definitely more, but the example above is one that I’ve encountered in the past (this was before the addition of DateTimeOffset to the BCL – my solution at the time was to explicitly store the time in the local timezone, and save the timezone information along side it: basically what DateTimeOffset does internally).
Answered by Dean Harding
Solution #5
DateTime does not save time zone information, whereas DateTimeOffset does. This is the most crucial distinction.
Despite the fact that DateTime distinguishes between UTC and Local, there is no explicit time zone offset. The server’s time zone will be used whenever you do any kind of serialization or conversion. Even if you manually construct a local time by adding minutes to offset a UTC time, you can still get a bit in the serialization stage since DateTime will utilize the server’s time zone offset (due to the lack of any explicit offset in DateTime).
If you use Json.Net and an ISO date format to serialize a DateTime value with Kind=Local, you’ll obtain a string like 2015-08-05T07:00:00-04. It’s important to note that the last component (-04) has nothing to do with your DateTime or whatever offset you used to create it… it’s simply the server’s time zone offset.
DateTimeOffset, on the other hand, expressly includes the offset. It may not include the name of the time zone, but at least it includes the offset, and if you serialize it, you’re going to get the expressly specified offset in your value instead of whatever the server’s local time happens to be.
Answered by Triynko
Post is based on https://stackoverflow.com/questions/4331189/datetime-vs-datetimeoffset