Azure Automation scheduler and daylight saving time
Update 18/10/16:
Azure Automation schedules do now support time zones, which means they can properly adjust for daylight savings!
To use this feature creating a new schedule is required - all existing schedules prior to the release of this feature will be stored in UTC.
Specifying a timezone in the portal looks like this:
Daylight saving time (DST) is the practice of moving clocks forward by one hour during summer months, so that the evenings are lighter.
Everything in Azure runs in Coordinated Universal Time (UTC), which is the primary time standard by which the world regulates clocks and time.
Azure Automation allows you to define time based schedules to run PowerShell workflows by. These schedules allow you to set a period of hourly, daily or a one-off, plus a start time. The start time input uses your local system time.
A worked example
Prior to 29th March 2015, my time zone was GMT, and I created a scheduler to run daily at 09:00. This would have been saved as 09:00 UTC when stored in Azure (GTM to UTC has an offset of 00:00, i.e. they are the same).
The clocks changed on 29th March 2015, so my local time zone is now BST (one hour ahead of GMT). Ideally, I would want the schedule to still be running at 09:00 in my local time, as it is starting a bunch of VMs that I want running during office hours only (to save some money!). However it is still saved as 09:00 UTC, which is 10:00 BST. Any Runbook associated with that schedule is now running an hour later.
Vote for this to be addressed
There is currently an open feedback item for this to be improved, so feel free to vote it up!
A note on schedules
At this point you are going to try and edit your schedules, to be back to the right local time.
However… you can't! The best you can do is to create new schedules for the right time, and link your runbooks to the new schedules instead.
This limitation means you might want to design your runbooks and schedules in such a way that the schedules can be reused across as many runbooks as possible. For example, have a generic schedule called DailyAt9AM, that does exactly that. That will at least limit the number of schedules you have to recreate.
In my previous post on using Automation to control when VMs are running, the Runbooks where generic and had parameters to determine which VM to start/stop. These parameters must be defined when you create the schedule, so using this approach you actually have few runbooks and many schedules, as opposed to the suggestion just made.
