Well, my vacation time is quickly coming to an end, and soon it will be the New Year!I'm consistently asked what the default date/time sttings are when deploying to Windows Azure. It may not be obvious to developers new to the platform. All Windows Azure servers utilize UTC time, and 'en-US' locale settings out-of-box. It is recommended to maintain applications that can convert local time (UTC) into the desired time/date formats.
You can see this by using remote desktop to "peer into and inspect" settings on your Windows Azure deployments. You will find that the server localization settings (Control Panel) are indeed set to "United States" for location, and "English (United States)" for Language Settings.For date/time settings, "GMT Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London" is the default selection, no matter which data center you are deployed to as well.
The Fabric Controller maintains operating system time synchronization for the system when roles are first booted. You could, with the latest SDKs. utilize administrative access startup scripts to change the localization settings (including local server time), but it is not recommended you do so. Doing so will introduce instability and the fabric controller may determine your role is out of sync. You will likely end up cycling your roles as fabric attempts to bring them to goal state in such a case. A better strategy is to write our applications to be aware that they actually run with UTC and default US CultureInfo settings.
For more info on manipulating Date/Time settings with .NET Framework 4.0, refer here: http://msdn.microsoft.com/en-us/library/5hh873ya.aspx
Another huge shortcut tip: Using Remote Desktop is extremely helpful to diagnose issues with Windows Azure, including ensuring an application you might want to script during startup, will actually install and run on the virtualized role images. You can Edit your Remote Desktop connection files (.rdp) by right-clicking the file saved to your desktop, and selecting Edit. This will enable you to map your local drive to the VM, so you can seamlessly transfer files to and from the role instance you are connected to.
I'm consistently using PowerShell, or Snippet Compiler (created by Jeff Key, and available at http://www.sliver.com), to output settings, or programatically manupulate objects.PowerShell is already on the Windows Azure role instances for your enjoyment, and Snippet Compiler take a few seconds to copy & paste into the C:\Applications folder on the VM to "play with".
Season's Greetings! Eric
What about applications, that are already built and do not handle UTC time properly?
We have migrated an existing application, changed the timezone to +1 and everything seems to work fine. We have a lot of datetime.nows in our code and chose to change the timezone in stead of the application code. what is wisdom in this situation?
Unfortunately, one of the costs of moving into the cloud with Windows Azure, and leveraging Microsoft's data centers,is that you will need to leverage principles of localization and internationalization. In many countries, this is the norm for developers whose applications need to span time zones, and for developers in other countries, it is a new horizon - the dawn of enhancing skillsets for the cloud. Every developer out there today IS A Windows Azure developer. Experience and expertise on the platform is what will set you apart as a specialist for cloud applications on Windows Azure.
Application migration will be more difficult in many cases than "new-new" applications, Considerations such as locale can be easily architected into new applications from the start, and these were likely of no concern when a developer's organization had more influence and control over the infrastructure. It sounds like your application should be evaluated more closely to ensure it will appropriately function in particular regions, and be able to respond at scale. Remember, any move to the cloud will result in having less control over the infrastructure and specialized hardware capabilities you may have previously enjoyed, but with the benefit of lower capitalization costs (and in many case, lower operational costs) for your organization.
While many customers are migrating applications today onto Windows Azure, there are certainly considerations and improvements that can be made to migrated applications for them to take full advantage of the Windows Azure platform characteristics, and DateTime settings are certainly one of those considerations.
Hope that helps.
Então, sem me preocupar com o TimeZone do Azure eu usuaria assim:
System.DateTime dt = System.DateTime.Now;
Agora, me preocupando com o TimeZone do Azure, eu transformo a data para o horario de Brasília
System.DateTime dt = System.DateTime.Now.ToBrasiliaLocalDateTime();
Veja o código do método de extensão:
public static class DateTimeExtensionsMethods
private static string TIME_ZONE_BRASILIA_ID = "E. South America Standard Time";
public static System.DateTime ToBrasiliaLocalDateTime(this System.DateTime dt)
System.TimeZoneInfo tz = System.TimeZoneInfo.FindSystemTimeZoneById(TIME_ZONE_BRASILIA_ID);
if (tz != null)
System.TimeZoneInfo tzSource = TimeZoneInfo.Utc;
if (dt.Kind== DateTimeKind.Local)
tzSource = TimeZoneInfo.Local;
System.DateTime adjustedDate = TimeZoneInfo.ConvertTime(dt, tzSource, tz);
throw new Exception();
catch (Exception ex)
throw new Exception("Não foi possível recuperar a Data e Hora de Brasília", ex); ;
I created service in Azure and code snippet to get actual Azure time