Do you want Time Zone support in System.DateTime? No, you don’t. Trust me. Every now and then I come across a blog posting or article about how Microsoft is investigating ways to extend System.DateTime to meet customer demand for time zone support. Basically, customers are asking Microsoft to make System.DateTime be able to represent a given date/time and UTC offset. This is bad for a number of reasons, but the biggest reason is that time zones SUCK!
Maybe you remember my quest to eliminate all of the evil that time zones have inflicted on me by converting my life to UTC while the world around me continued ignorantly using Eastern Standard Time? Well that didn’t go over too well because interacting with other people was just too difficult. Fortunately, computers don’t have that problem. If you follow these simple rules, you can live a happy pain-free coexistence with DateTime.
- Never, ever, ever store a DateTime in its local time. By storing all DateTimes in UTC, you guarantee that you can always accurately convert it to any time zone quickly and issues such as daylight savings crossovers and politics won’t cause issues. (Tip, use GETUTCDATE() in MSSQL and DateTime.UtcNow in .NET)
- Never transfer DateTimes over the network in local time. Always use UTC because you don’t want to get into a situation where your application’s architecture won’t scale geographically because it expects the client and server to be in the same time zone.
- Only use local times in the user interface when presenting a DateTime to a human or accepting a DateTime as input from a human. When you read the time, assume it is local time zone (unless your UI has a mechanism for specifying the time zone like Outlook finally does) and then promptly convert it to UTC using DateTime.ToUniversalTime() for storage or transport. When you’re displaying a DateTime from the database for a human to read in a report or window, use DateTime.ToLocalTime().
- Note that I haven’t mentioned the DateTimeKind enumeration. I find this extension to DateTime to be completely unnecessary. If you followed the above rules, then there is no need to tell whether a date is local or utc.
Also, DateTimeKind is a total hack and does not protect you from making multiple calls to ToLocalTime() or ToUniversalTime() which will keep offsetting the date. If you follow the rules above, there is no need to protect against this.
So does this mean I think .NET is completely sufficient when it comes to dates and times? Not by a long shot. But I don’t think the DateTime structure itself needs to be modified. In fact, I think it’s the TimeZone class that needs to be enhanced. Here’s what I’d like to see added to TimeZone.
- static TimeZone[] TimeZone.GetAllTimeZones()
- static TimeZone TimeZone.FromName(string name)
- string TimeZone.Rfc822Name { get; }
- string DateTime.ToRfc822String(TimeZone tz)
- DateTime DateTime.FromRfc822String(string rfc822String)
Currently, only the local time zone is supported by the TimeZone class. I would like to see all the same time zones in the Windows registry (as seen in the date/time control panel applet) supported. Second in my list is a way to get a TimeZone from a name such as “Eastern Standard Time” or “EST”. This way you could parse out the time zone or UTC offset often found in internet email messages (see RFC 822). Third on my list is basically the reverse of #2, that is, the ability to get the standard name for the time zone. Fourth on the list is the ability to convert a DateTime to a localized time zone for an internet message. But if you follow my recommendations at the beginning of this post, you should be sending all your dates as UTC!! Finally, the ability for DateTime to parse a RFC 822 date header. The return value would always be in UTC, but unlike the current implementation, it wouldn’t ignore the offset. So if the date was: Thu, 31 Aug 2006 06:23:59 -0400, then it would be parsed as a UTC DateTime with the value 8/31/2006 10:23:59.
So anyway, what I’m basically saying is leave DateTime alone and fix TimeZone. :)