Schedules: Time Zone Support
Important
A curator (Server admin) has to enable the user permission to schedule jobs before you can begin scheduling workflows. Curators can learn how to enable scheduled workflows for users in the Schedules: Admin Interface and Jobs: Admin Interface articles. Once a curator has enabled the user permission for you to schedule jobs, the link to the Schedules page appears on your Server UI toolbar.
All schedule frequencies have an option to select the time zone for which it is run. If your schedule is set for a time zone that observes DST, please see the Recommendations for End of Daylight Saving Time (DST) section to read about some known limitations related to DST.
Schedules display on the Schedules page in your user-preferred time zone, regardless of the scheduled time zone.
Note
An alert displays next to jobs that do not have an associated time zone. These schedules were created prior to version 2019.3 or were migrated from Desktop Automation. Select Update to update to your current time zone or Dismiss to leave as originally scheduled.
Set Your Server Time Zone
Set your preferred time zone in your Server profile. Select your Username > My Profile > General.
When you return to the Schedules page after changing your preferred time zone, the schedules will show in your new time zone. Changing your time zone will not affect when schedules run.
Note
With the end of Daylight Saving Time (DST), there is one hour that occurs twice within the same day. For example, in the USA, the end of DST happens on November 6, 2022 and the hour between 1 AM and 2 AM occurs twice.
This time change might cause issues with your scheduled runs.
We recommend taking these steps to prevent issues due to the time change:
For new Server instances, proactively set your independent Controller nodes to UTC (Coordinated Universal Time). We recommend that you also set the Worker and Server UI hosts to UTC, although this is not required.
For existing systems, we do not recommend adjusting the time zone of the Controller unless necessary. Changing the time zone causes existing schedules to shift.
For example, if the Controller is currently configured for MDT (UTC-6), moving the time to UTC will shift all schedules by +6 hours. Additionally, the timestamps for all job results before the change will be skewed by the same offset.
Any schedules run during the DST time change will have the next run times updated appropriately so that they don’t run twice. There will be an hour gap when the clock roles back where schedules won’t run because that hour is repeated.
As an example, using the USA DST on November 6 between 1 and 2 AM, let's consider a schedule that runs every hour at 15 minutes past the hour. This schedule will run normally at 1:15 AM and update its next run to 2:15 AM. At 2 AM, the clock moves back to 1 AM. Since the schedule already ran at 1:15 and updated its next run time to be at 2:15 AM, it will wait until the time reaches 2:15 AM to run again. So, the schedule will run at the correct times, however, there will be a 2-hour gap between runs instead of the normal one-hour gap.
When time jumps forward an hour, any schedules set to run during that missed hour will get in the queue to run immediately. Depending on the configuration of the schedules, this might cause an ongoing skew.
Let’s consider the same example where the schedule runs every hour at 15 past the hour. In the spring, this schedule will start at 1:15 AM and be updated to run again at 2:15 AM. However, when 2 AM arrives, the time will move to 3 AM. Server will see that this schedule was supposed to run at 2:15 AM but it did not. Server will solve this by adding it to the queue immediately (3:00 AM). It will also update the schedule to run again in one hour (4:00 AM). This will cause all subsequent schedules to run on the hour, instead of 15 minutes past the hour.