This is based on an email I send my .NET team at work
Just one this week but there’s multiple related articles at the bottom.
So if you’ve done much with building support for timezones, you know its
confusing and tricky. A lot of that is because the built in
System.DateTime struct is not expressive enough to capture all the
intricacies of the way humans think about dates and time.
We think of all of these in different contexts:
- A date with no real time (my birthday)
- A time with no specified date (when is lunch)
- The instant something happened, regardless of what timezone you are in
- The time in my current timezone
- The time in my friend’s timezone
- The time in some mythical UTC thing
But DateTime is all you’ve got in .NET to represent all of these concepts.
Jon maintains Noda Time which attempts to address the shortcomings of DateTime through a more expressive type system.
If we get a project with some heavy requirements around timezones, a library like Noda Time could be a great tool to have in our back pocket. And even if we don’t choose to use it, I think it’s really helpful to understand the concepts that drive the design decisions of the library so that we can avoid bugs in our own code.
If you want to find out more about it, check out: