Azure now returns invalid value of "Coordinated Universal Time" for TimeZoneInfo.Local.Id instead of "UTC"? Why?

Question

It appears starting March 7 that Azure servers in the Southeast Asia region had a patch applied which changed the behavior of TimeZoneInfo in .NET.

Setting my local machine to "(UTC) Coordinated Universal Time", then running the following code yields "UTC":

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(TimeZoneInfo.Local.Id);
            Console.ReadLine();
        }
    }
}

Remoting into one of our Azure instances and running this same application yields the following:

"Coordinated Universal Time"

According to .NET documentation, this is the value that should be returned by the StandardName property, not the Id property. We pass this value in to TimeZoneInfo.FindSystemTimeZoneById(), and it fails since "Coordinated Universal Time" is not a valid Id ("UTC" is). This timezone is one of only 3 whose StandardName property does not match the Id property.

Prior to March 7, Azure instances always returned the proper value of "UTC". We have hardcoded "UTC" for the time being as a stopgap solution.

Does anybody have any idea why this changed to be this way, and what is the proper long-term solution to handle this situation?

Answer 1

Currently, the time zone within Windows Azure is Pacific Standard Time (PST). They have migrated to Coordinated Universal Time (UTC). This is potentially a breaking change for applications which rely on local time.

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 the global customer base, and UTC is not subject to Daylight Saving Time (and the associated risk of bugs).

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.

If you want them to change it back or if you have any other issues, you can take it up with them on the following blog link ::

Windows Azure blog