Azure moves time to UTC, and Tesco's place in the Azure cloud

I predicted in an earlier post that the Windows Azure platform team were going to have to have a serious think about what they do about time in the Azure cloud.

Well I've just come back from holiday to find in my inbox a message from the team saying that Azure is going to move from local time (Pacific, which happens to be the time zone where Microsoft HQ in Redmond is located) to Coordinated Universal Time (UTC) - that's Greenwich Mean Time (GMT ) to us in the UK.

In their message, the Azure team say:

Currently, the time zone within Windows Azure is Pacific Standard Time (PST). Soon, we will be migrating to Coordinated Universal Time (UTC). This is potentially a breaking change for applications which rely on local time.

When will we make the change?
We will start rolling out this change starting Sunday, March 8 at 10:00 AM GMT.

Why are we doing this?
Windows Azure is a global service. To ensure that applications behave the same way regardless of their physical location, it’s important that Windows Azure have a consistent time zone across all geographies. UTC is a natural choice given our global customer base, and UTC is not subject to potentially disruptive changes in Daylight Savings Time.

What’s the potential impact to you?
If your application running in Windows Azure relies on local time, you will be impacted by the migration to UTC. Here are a few examples of potential issues:

• Gaps may occur in event logs if local timestamps are used.
• User interfaces that depend on local timestamps may show different results.
• Local timestamps stored by your application may be interpreted differently after the changeover.

Many applications have already been designed to rely only on UTC time. These applications should be unaffected.

The good news is that those of us thinking of the global nature of Azure will have been using the System.DateTime.UTCNow property to obtain time rather than using System.DateTime.Now if only because Pacific time was probably inappropriate to our applicatons unless coding for users located on the USA's Pacific coast.

The bad news is that of course we need to use time that is local to our user market, which means that we need to convert UTC to local time and then deal with summer/winter time within each application.

I'm still holding out for a setting in Web.Config that performs the equivalent of setting the local time zone on a Windows server and let it handle time moves just as happens today. Doing this at application level for Azure would mean that it would be flexible and easy to bring different time-zone versions of the same application to different countries.

Finally I'm happy to say that I've secured Tesco a place in the Azure cloud domain at http://tesco.cloudapp.net - I'll put something appropriate up there shortly (once my holiday completes tomorrow night!). The Tesco.com Grocery API will go up there shortly and I'll make sure that colleagues throughout Tesco wishing to try some 'R&D in the cloud' can get access - just contact me from your Tesco account to mine if you would like to do so.