Knowledge Base

Scheduled Tasks and Daylight Savings Time

Last Modified:
05 Oct 2022
User Level:
Administrator

Daylight Savings Time (DST) has been, up to now, problematic for scheduled tasks like publish and transfer times. When the hour went forward (in spring) or back (in fall/autumn), scheduled publishes and transfers could deviate off schedule.

From 8.3.14, when DST occurs, an offset (-/+ 1 hour) will be applied to the next execution time to keep the schedule running as it did before.

These DST changes are not applied when "Fixed rate" is enabled on a scheduled task.

The problem

Here's a typical case where the clocks have moved forward by one hour in spring:
  • Execution time: March 26th, 2022, at 11PM (GMT)
  • Interval: 2 hours
Execution count
Date
Next execution
1
March 26th, 23:00
March 27th, 02:00
Daylight saving time is applied on March 27th, 2022, at 01:00, so the next execution time is moved to 02:00
2
March 27th, 02:00
March 27th, 04:00
Instead of 03:00, that would have been the expected hour.
3
March 27th, 04:00
March 27th, 06:00
 
Problem: Due to daylight saving, the schedule has changed to be executed every even hour instead of every odd hour.

The solution

Now, in 8.3.14, an execution will be skipped, and the offset will be applied to ensure the execution schedule remains on track:
  • Execution time: March 26th, 2022 at 11PM (GMT)
  • Interval: 2 hours
Execution count
Date
Next execution
1
March 26th, 23:00
March 27th, 03:00
The execution scheduled for 02:00 will be skipped because the interval of 2 hours is lower than the skipping threshold (4 hours)*. The offset of -1h is added to subsequent executions.
2
March 27th, 03:00
March 27th, 05:00
The scheduling returns to the usual execution schedule.
3
March 27th, 05:00
March 27th, 07:00

Solution: An offset has been applied to keep the executions to the same schedule.

  • A skipping threshold of 4 hours is set to ensure that previously scheduled executions are complete before the next scheduled execution occurs. This is to avoid the next execution starting while another is underway.

Other cases

  1. There's a four-hour interval between the execution start and the next execution begins when the clock moves forward; in that case, the next interval is offset by minus 1 hour.
  2. There's a four-hour interval between the execution start and the next execution begins after the clock moves forward; in that case, the next interval is also offset by an hour.

Back to top