When Would You Prefer DateTime Over DateTimeOffset

孤人 提交于 2019-11-27 11:53:24
Jon Skeet

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

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

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!