59

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

Bob Horn
  • 33,387
  • 34
  • 113
  • 219
Omer van Kloeten
  • 11,800
  • 9
  • 42
  • 53
  • Related question - http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices – Oded Jul 23 '10 at 20:22
  • 1
    See also [this answer](http://stackoverflow.com/a/14268167) – Matt Johnson-Pint Jan 11 '13 at 00:51
  • Does this answer your question? [DateTime vs DateTimeOffset](https://stackoverflow.com/questions/4331189/datetime-vs-datetimeoffset) – TylerH Feb 21 '22 at 15:28
  • That link doesn't take me to the article. This one does: https://learn.microsoft.com/en-us/archive/blogs/bclteam/datetimeoffset-a-new-datetime-structure-in-net-3-5-justin-van-patten – wildbagel Jul 28 '22 at 21:05

3 Answers3

60

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

Community
  • 1
  • 1
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 3
    You could always represent your times in UTC and convert to a specific time zone when needed... – Omer van Kloeten Nov 05 '08 at 09:04
  • 3
    Omer: But often you want to preserve the timezone information as well, I find. Yes, often you can get away with just the UTC time, but for recurrent events and the like you need to know the timezone too. – Jon Skeet Nov 05 '08 at 09:25
  • Local time should usually only be used for future dates, where you want them to adjust with timezone changes. Historical data should always be stored in a consistent time zone, probably UTC though there may be historical reasons for another. (Example: for NYSE transactions data you might want EST across the board). – Ben Mar 10 '11 at 19:04
  • 9
    @Ben: You're thinking about *instants* in time though. Not everything is like that. For example, "my birthday" is June 19th, every year - past, present and future. Or "the first day of the year 2000", which started at a different instant in each time zone. Or "6am" of my alarm clock. Basically it's worth making sure you know what kind of thing you're really representing. – Jon Skeet Mar 10 '11 at 19:15
3

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

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • True, but I was actually talking about internally in my code and in the UI layer. – Omer van Kloeten Nov 05 '08 at 09:11
  • 2
    Fair enough. I thought I'd mention it because VS multi-targetting doesn't make it obvious when you've used SP1 features while allegedly targetting 2.0. There is now an FxCop (etc) add-in to do this, at least. – Marc Gravell Nov 05 '08 at 09:14
0

Whilst I wouldn't PREFER to use DateTime over DateTimeOffset, please note that sometimes you NEED to, as MS .Net does not support DateTimeOffset as a DataColumn.DataType property DataColumn.DataType Property even though SQL datetimeoffset has been around since SQL2008.

I myself had a problem with reading (ReadXml) a DateTimeOffset value of an XML exported DataSet with XmlReadMode.InferTypedSchema; it read it as a DateTime and crashed when I tried to merge it into a DateTimeOffset column

brewmanz
  • 1,181
  • 11
  • 17