Endjin - Home

Azure Automation scheduler and daylight saving time

by Richard Kerslake

Daylight Savings_Principles_Principles


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:

azure-automation-schedule-with-timezone


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.

azure-automation-scheduler

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.

About the author

Richard is a Software Engineer and certified Microsoft Cloud Platform developer, providing strategy, insight and engineering services. He has a background in financial services, working on large scale distributed trading systems. Richard has a passion for delivering real business value to endjin’s clients, who are seeking to take advantage of Microsoft Azure and the Cloud. You can follow Richard on Twitter.