Menu
A few months ago I was introduced to the new DateTimeOffset type and was glad DateTime's flaws with regard to time zones were finally taken care of.
However, I was left wondering if there were any overhead or problems that could occur from using this new type.
I work on a multi-locale web application. Does anyone know of anything that could sway me from just using it for all my date/time work? Is there a window for abuse here?
Reference: DateTimeOffset: A New DateTime Structure in .NET 3.5 by Justin Van Patten
827
With its Kind property, DateTime is able to reflect only Coordinated Universal Time (UTC) and the system's local time zone. DateTimeOffset reflects a time's offset from UTC, but it does not reflect the actual time zone to which that offset belongs.
DateTime values lack any knowledge of time zone, or lack thereof. If you need to know when things actually occurred, with more precision than just the approximate date, and you can't be 100% sure that your dates are ALWAYS stored in UTC, then you should consider using DateTimeOffset to represent your datetime values.
Uniquely and unambiguously identify a single point in time. The DateTimeOffset type can be used to unambiguously define the meaning of "now", to log transaction times, to log the times of system or application events, and to record file creation and modification times.
The TimeSpan struct represents a duration of time, whereas DateTime represents a single point in time. Instances of TimeSpan can be expressed in seconds, minutes, hours, or days, and can be either negative or positive.
Sometimes you really just want to represent a "local" (timezone unaware) date and time rather than an instant in time. To be honest it's more often useful to represent just a time - e.g. "wake me up at 8am, regardless of timezone" - but date and time could be useful too.
I agree that for the vast majority of cases, DateTimeOffset is a better fit. It does strike me as odd that there isn't a DateTimeTimeZone struct which has both the instant and its timezone though... an offset doesn't actually give you all the information you need. (For instance, given a DateTimeOffset, you don't know what the time will be 24 hours later, because you don't know when DST might kick in.)
If you want that kind of structure, I have a very crude implementation in another answer. I'm sure it could be improved very easily :)
198
Well, one obvious answer would be when you need to support clients without the SP that it ships in (it isn't actually in 3.5 - it is in 2.0 SP1, which shipped at the same time).
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
