<p>A few months ago I was introduced to the new <a href="http://msdn.microsoft.com/library/system.datetimeoffset.aspx" rel="noreferrer"><code>DateTimeOffset</code></a> type and was glad <a href="http://msdn.microsoft.com/library/system.datetime.aspx" rel="noreferrer"><code>DateTime</code></a>'s flaws with regard to time zones were finally taken care of.</p>

<p>However, I was left wondering if there were any overhead or problems that could occur from using this new type.</p>

<p>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?</p>

<p>Reference: <a href="http://blogs.msdn.com/bclteam/archive/2007/06/14/datetimeoffset-a-new-datetime-structure-in-net-3-5-justin-van-patten.aspx" rel="noreferrer">DateTimeOffset: A New DateTime Structure in .NET 3.5 by Justin Van Patten</a></p>

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 :)