DateTime vs DateTimeOffset

[DavidThielen]

Hi all;

I have found DateTimeOffset to be problematic. The big problems are:

1. When a timezone shifts to/from DST is a political decision and has happened at times with 1 week notice.
2. 2:00pm Denver time is a different UTC offset in December than in July.
3. You can't adjust for DST because Arizona has no DST so you don't know if you're Pacific Time or Arizona Time in the summer and so don't know if you need to adjust when DST hits.

What I came up with decades ago, and it has worked great, is to treat it as a combined DateTime+TimeZone. I wrote a class DateTimeZone which does this. I have it up on GitHub and NuGet.

Hopefully this will help those of you hitting the same issues I hit with DateTimeOffset.

thanks - dave

[elgonzo]

Take a look at nodatime. It has extensive time zone support based on IANA's time zone database (see here: https://nodatime.org/TimeZones). Nodatime's equivalent for the DateTime+TimeZone combo is ZonedDateTime.

I think i'm not going out on a limb here by saying nodatime is the go-to library for anyone who needs more date/time-related features than DateTime/DateTimeOffset offers. (nuget lists a whopping 157 million downloads for nodatime)

[DavidThielen]

I agree nodatime is great. My DateTimeZone is useful if that's the only thing you need. If you need more datetime functionality, then nodatime is the way to go. (There's also Yoda Time - used a long time ago in a galaxy far, far away.) I'll add a note to that effect in my readme.

[Clockwork-Muse]

I could have sworn we had an open issue for this, but I'm not finding it at the moment.
A DateTimeZoned type has come up multiple times in other issues relating to date-time though.

[DavidThielen]

You are welcome to use this, either as-is or revise/extend it. It is posted under the MIT license.