Hey Azure! What Time Is It?

Recently I’ve seen a few places online where people where essentially asking, “Hey Azure!  What time is it?”  The more I thought about it, it seemed like an interesting question that I have not seen many answers for. 

In an attempt to answer this question, I put together a simple application which demonstrates how date/time is handled in Windows Azure.  But before getting into the code, let’s talk a little about affinity regions in Windows Azure.  

Windows Azure - Affinity Selection

Windows Azure - Affinity Selection

When you are setting up the options for your Azure service deployment, one of the options you will have is a deciding where you want your application(s) to physically run.  You can select from the Windows Azure data centers located in the United State, Europe, or Asia.  

If you have multiple hosted services and/or storage services which are part of your application (e.g. a web role and table storage), you will likely want to create an affinity group and keep everything within the same region.  This will reduce the latency of the application(s), and probably save you some money two.  If, for example, your web role is in the “North Central US” affinity region, but your storage service is in the “Anywhere Europe” region, then your application (and therefore your users) will experience additional latency while the requests traverse the internet to a European data center.  If the web role and storage services where in the same region, they would actually be in the same data center, thereby greatly reduce any latency.  Additionally, since you are charged for bandwidth consumption for data flowing into a data center, you would be paying for the traffic between the two data centers.  By keeping your solution in a single data center you will save yourself a nice chunk of change.  If you would like to learn more about Windows Azure’s affinity options, take a look at this post from the Windows Azure Team Blog. 

 Now that we’ve got a little background on Windows Azure affinity regions out-of-the-way, let’s answer the question of what time is it.  To do this I put together a very simple ASP.NET Web Role project which will display the current date and time, along with a few other simple pieces of data about my Windows Azure instance.  The code is pretty basic:  

The code.

 I can now take this ASP.NET Web Role project, deploy it to Windows Azure, and see what time it is.  Before doing so I created hosted services on my Windows Azure account – one set for the “North Central US” affinity region, and the other set for the “Anywhere Europe” affinity region.  The “North Central US” data center should be the Windows Azure data center in Chicago, IL.  As for the European one, it could be one in Dublin, Ireland, or anywhere Windows Azure decides.  This distribution should give me two examples to work from where the data centers are pretty far apart.

 I started by deploying my simple web app to the data center in the “North Central US” region.  Perhaps you would expect the datetime to be the current US Central time.  As you can see in the screenshot below, the time is actually the current UTC time.  

Eastern Central US

I then deployed a copy of that same simple web app to the datacenter in the “Anywhere Europe” region.  Again, the time is the current UTC time. 

Anywhere Europe

Both apps are displaying the current UTC time.  But why?  The reason is Windows Azure is a global service.  Regardless of where the application is running it should behave the same.  By using UTC, this ensures a consistent experience for everybody on the platform.  I know many developers who when writing their application simply use DateTime.Now.  If your app does this, and you are considering a move to the cloud with Windows Azure, be sure to keep in mind that “now” is UTC time, and that might not jive with the logic in your application. 

 For what it is worth, there is also a post on the Windows Azure Team Blog site from March 2009 stating the change from Pacific Standard Time to UTC time.  I simply could have answered the original question by referencing this post .  . . . but that wouldn’t have been nearly as much fun!