Allow scheduling jobs based on timezone
Currently, you can only schedule jobs based on a fixed time offset from GMT. This means the actual local time when the job runs will change one hour forward or backward, in spring and fall when daylight savings change.
John Bergdahl
shared this idea
10 comments
-
Brandon Poe [MSFT]
commented
We support time zones in the Azure Automation scheduler service. Azure Automation allows you to write code in PowerShell and execute it on a schedule. If you need time zone support now, I encourage you to check it out.
https://docs.microsoft.com/en-us/azure/automation/shared-resources/schedules
-
Brad Ruoff
commented
^This. Please allow us to create schedules for specific timezones.
It seems possible to do so through the portal... so why not through the REST API and/or the Azure Scheduler .NET SDK?
-
stephen eggering
commented
I just received a response to my trouble ticket on this, and it was basically "You can go upvote it here", but it's not in place yet. The other suggestion was to create a hacky powershell or bash script.
-
Andrew Thomas
commented
Any update on this?
-
William
commented
I hope my kids one day will be able to schedule jobs based on timezone. Until then, I will have to change my 200+ jobs manually or thru a hacky powershell script!
-
Martin
commented
Its been more than a year since this was planned, is there any indication when this will be started and completed?
-
JeffC
commented
This is the #1 missing feature that prevents me from going live with Azure Scheduler. I have jobs that need to run at specific local times across timezones all around the world.
Examples: job1 run at 3am PST Los Angeles, job2 run at 3am EST New York, job3 run 3am IST Dublin.
For a scheduler to work for our needs there must be the ability to schedule the job to run in a specific timezone and then the scheduler must account for daylight savings time to be sure the job always runs at the correct local time.
We are using a home grown scheduler that is short on features and I'd like to leave it to run on Azure but timezone and DST support is a showstopper for us. Our homegrown system has been able to handle this for years. A few lines of C# can handle the conversion between future job schedule time and UTC and will account for what the target timezone DST offset will be (if any) at the scheduled date and time.
-
William
commented
Any news on this?
Schedulers on Azure Automation Runbooks have this now.
-
Remco Lam
commented
I think the most important thing is to actually be able to schedule in timezone specific times. If a job should run at 1AM local time, I should not have to change the schedule during DST changes.
What happens during a changeover is mostly a bonus. If a job would be run twice if it's run at 2.30 AM or not at all (depending on which changeover is a happening, than that is completely by design. This can be worked around on by not scheduling anything during the DST overlap period.
Remco
-
Eric Barnard
commented
I appreciate the clarity on the UTC timing - that makes sense. As far as your questions:
1) If it's a daily/weekly/monthly job, then I would expect it to be ran at 2:30 am - as a daily job, I expect it to be ran at least once in that interval. If it's a job ran at minute intervals (e.g. every 15 mins), then do as the world does for DST and ignore the intervals going from 1am to 2am by just continuing to execute every 15 mins.
2) If its a daily job, I would NOT want my job to be called 2x in a 23-hour period ... if I have a 12:30am job and it just executed successfully 1 hour ago - DO NOT EXECUTE it again. I would think one of the most common scenarios for use of the scheduler is not necessarily 'clean up jobs' - but things more like automated email sends and other tasks that would cause my end users confusion. Again though, if the job is on a minute interval, just continue calling on that interval and ignore the fact that it might be the same time all over again.
I think my point is that jobs that execute on a Daily/Weekly/Monthly type of schedule are very different in their goal from jobs that execute at minute/second level intervals.