Recently I had correspondence with HR from Great Britain. In one of the e-mails I wrote “16:00 CEST (UTC+2) would work for me” which confused the guy, so he asked what GMT UK time it is. If I was too much pedantic I could have replied that GMT is ~same as UTC and that in GMT it is 14:00. But of course it would confuse him even more. I replied with “3PM” as it was corresponding time in UK.
Problem is that 3PM (or 15:00) is not GMT time, but rather “GMT Standard Time + Daylight Saving Time” and when you look it up it is better called BST – British Summer Time. On the other hand I also understand that for many people it is much easier to refer to their time zone as GMT (maybe for historical reasons).
I wouldn’t write this blog post if confusion was only in heads of ordinary people. Unfortunately big enterprises and small startups still frequently fail to write proper time zone handling in their applications.
Lets start with this: We no longer argue whether Earth is orbiting Sun or the other way around, the same way we no longer depend on some astronomical events to measure time, although none would like if at 1PM it was night. There is atomic clock invented which is ultimate truth of time, but since Earth is not spinning that precisely Coordinated Universal Time (UTC) has been developed. GMT is historical term and it would be great to leave it aside.
If you want to understand modern time measurements I would strongly recommend to read these two articles: Coordinated Universal Time (UTC) Explained and GMT and Other Time Systems Explained.
Now bit more for not so ordinal people
When it comes to source code things are not getting much cleaner. Answer to question “Difference between UTC and GMT Standard Time in .NET” at SO:
GMT does not adjust for daylight savings time. You can hear it from the horse’s mouth on this web site. Add this line of code to see the source of the problem:
Console.WriteLine(TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time").SupportsDaylightSavingTime);

 

Output: True.
This is not a .NET problem, it is Windows messing up. The registry key that TimeZoneInfo uses is HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTime ZonesGMT Standard Time
You’d better stick with UTC.
And I partially agree that it is Windows messing up for few reasons. If you look at corresponding to registry entry “GMT Standard Time” UI:

image 

you will notice that it is displayed as UTC, but it is also DST adjustable. Now when you read this MSDN page about TimeZoneInfo, you will get an impression that “standard times” are not DST adjustable, but when converting in .NET it actually takes daylight into account. Concluding I’m afraid that when dealing with time zone conversions we have to be very cautious.

Conversion itself can be done utilizing class TimeZoneInfo (same link again):

 

TimeZoneInfo GMT = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
DateTime postDateUtc = TimeZoneInfo.ConvertTimeToUtc(dbRecord.PostDateInLocalLondon, GMT);

And please be careful. You would need some exception handling and be ready for not-existing or ambiguous time. For example, see how this:

TimeZoneInfo GMT = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
DateTime notExistingInGmtTime = new DateTime(2013, 3, 31, 1, 30, 0, DateTimeKind.Unspecified);
DateTime dateInUtc = TimeZoneInfo.ConvertTimeToUtc(notExistingInGmtTime, GMT);

would throw an exception. Reason is that there is no such time as 1:30AM on 31 March 2013 in London.

How to work with Time, Dates and Time Zones in .NET
Everything starts with basics. If you get them wrong how do you expect to write quality code? It is not a shame to read again about DateTime or even Boolean. Deep inside there is always something hidden – it just depends on depth.
In my career I’ve experienced quite many (as for such fundamental concept) different problems and inconveniences because of incorrect handling of time.
My rules of thumb:
  • Always persist date and time in UTC, otherwise save offset, but never-ever local time
  • Use DateTimeOffset – it is DateTime v2, otherwise at least make sure to avoid DateTime pitfalls
  • Be explicit about TimeZone used, in APIs I would also call date&time fields with suffix “Utc” (ugly?)
  • Convert to local time just before displaying
  • … and check for best practices over internet
Before finishing this post I would like to mention I have a task for myself as well: exploring Noda Time. If you haven’t read What’s wrong with DateTime anyway? you should!
… and, sorry but had to copy one final issue…
If it is Coordinated Universal Time, why is the acronym UTC and not CUT? When the English and the French were getting together to work out the notation, the french wanted TUC, for Temps Universel Coordonné. UTC was a compromise: it fit equally badly for each language. :)