If you’re anything like me, you’ve probably learned that it’s a bad idea for your applications to take a dependency on the time zone configured on your servers, as it makes your code less portable and can lead to unexpected behaviours if anyone ever tinkers with the server settings. (It’s also a bad idea for your application to store dates in anything other than UTC time, but that’s another story).
However in the real world, you’ll occasionally need to deal with legacy codebases that aren’t designed the way you’d want. While updating a single call to be time-zone agnostic normally isn’t hard, finding and fixing such calls that are scattered all over a large solution will often be time consuming and unacceptably risky. So if you want to put such a solution onto Azure, you’ll need a way of setting the time zone to something other than the default UTC settings.
Today there are three Compute engines in Azure that you can choose from, and the approach for customising the time zone differs for each.
If your app is hosted on Azure Virtual Machines, you have complete access to the VM so you can configure the time zone to whatever you want.
If your app is hosted on Azure Cloud Services, it is possible to write a startup script that calls the tzutil utility to change the time zone; however this isn’t recommended and can apparently lead to instability.
If your app is hosted as a Web App on the Azure App Service (formerly known as Azure Websites), until recently you were completely out of luck. However there is now an easy and supported way to change the time zone for your w3wp process (and any processes it spawns):
All you need to do is add an Application Setting (via the portal or the management APIs) called WEBSITE_TIME_ZONE and set that to the name of the time zone as defined in the Windows Registry under HKLMSoftwareMicrosoftWindows NtCurrentVersionTime Zones (for example, “AUS Eastern Standard Time”).
So now you know how easy it is… go and fix your code so you’ll never need to use this!