Running Code on Windows Azure? Set the time zone of your development machine to UTC (Coordinated Universal Time)!

Its no secret that Windows Azure Roles, Services and SQL Database Time Zones  are set to
UTC (Coordinated Universal Time). Forgetting this fact can get us in trouble! When we forget about
Time Zones, any operations dealing with dates and times are potential bugs!

For example

• Scheduling jobs
• Comparing dates and times
• Performing operations on dates and times
• Parsing string dates and times from the client
• Storing dates and times in SQL Database

We naturally refer to time using our current Time Zone. Imagine that a system requires a specific Job to run every Monday at 16h05 GMT –5. Its very likely that I will create a new DateTime instance that represents 16h05 and that I will happily use it to schedule my daily Job.

At some point, someone is going to notice that something is off. The Job is running, but it’s not producing the expected results. Furthermore, its not running on the right schedule. So we have one of those “Weird this works on my machine!” moments. So you fire up the Windows Azure Emulator, run the jobs locally and everything is just peachy. At this very moment frustration start to set in… There’s just no logical reason that comes to mind…
The code runs perfectly. Everything is the same… But wait! The Time Zones are different! My machine runs in
GMT –5 and Windows Azure runs in UTC.

So the Job is running properly on Windows Azure, its just not running in the right Time Zone.
Its also comparing dates and times from different Time Zones… Its no surprise that everything doesn’t perform
as expected.

After spending a few hours figuring this out, I decided to change my development machine Time Zone to UTC.
Ok fair enough, many of you out there are going to argue that its impractical! But remember that we have phones, watches, clocks and colleagues to keep us informed of the local time.

What we don’t have, is the natural reflex to think in UTC (Coordinated Universal Time)

Having my machine set to UTC helps me remember that my code needs to take Time Zones into consideration. Furthermore, having my development machine’s Time Zone set to UTC will also ensure that my debug session run in UTC and not on local time.

I’ve made the change a little over a week ago and I became used to UTC quite fast. I was also able to spot and fix a few date and time related bugs without having to spot them in staging or production.

The following technique can be used to convert between Time Zones. You can also find a complete list of Time Zone Identifiers on a previous blog post about scheduling Jobs on Windows Azure.

TimeZoneInfo.ConvertTimeBySystemTimeZoneId(now, "US Mountain Standard Time");

Use DateTimeOffset to create DateTime objects in UTC. It represents a point in time, typically expressed as a date and time of day, relative to Coordinated Universal Time (UTC).

var dateTime = new DateTimeOffset(2013, 01, 01, 0, 0, 0,new TimeSpan(0));

References

• Get the current time in UTC  at Time.is
• TimeZoneInfo
• TimeZoneInfo.ConvertTimeBySystemTimeZoneId
• DateTimeOffset Structure