What happens when the time changes for DST in the Spring and Fall?

Document ID : KB000011820
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

 

Daylight Saving Time

 

CA Workload Automation DE observes daylight saving time (DST) depending on where it is installed in the world.

 

For example, in Sydney, Australia, DST is observed; spring forward occurs at 2:00 a.m. on the last Sunday of October and fall back occurs at 3:00 a.m. on the last Sunday of March. Some places, such as Phoenix, USA and Regina, Canada, do not observe DST.

 

Question:

How does CA Workload Automation DE (dSeries) handle Daylight Savings Time (DST) change?

Environment:
Windows; Unix
Answer:

Spring-Forward Adjustments

In the North American Eastern Standard Time Zone, DST starts on the second Sunday of March at 2:00 a.m.; the time springs forward one hour to 3:00 a.m. The following illustration displays DST spring forward:

This illustration displays DST spring forward.

Events that are scheduled to run during the spring-forward transition period (2:00 a.m. to 3:00 a.m. on the day spring forward occurs) run immediately after the transition at 3:00 a.m. For example, Event A is scheduled at 2:30 a.m. on March 11, 2007. At 01:59:59 a.m., the time springs forward to 3:00 a.m. At 3:00 a.m., the server considers Event A overdue and triggers the Event immediately.

At the job level, if a job has a submission time of 2:30 a.m., the server submits the job at 3:00 a.m. (assuming all other dependencies have been met). For example, Event B is scheduled daily, suspended at 2:30 a.m., and resumed at 5:00 a.m. On March 11, 2007, the server suspends the Event at 3:00 a.m. and resumes the Event at 5:00 a.m.

The server adjusts the times for the following to 3:00 a.m. if they fall in the spring-forward transition period:

  • Event simulation for the current year
  • Event trigger
  • Event schedule criteria (resume and suspend times)

    Important! The server does not allow an Event’s suspend and resume times to both fall in the spring-forward transition period. For example, if the suspend time is 2ND SUNDAY OF MARCH 2:20AM and the resume time is 2ND SUNDAY OF MARCH 2:50AM, the server resolves both times to 3:00 a.m., which is not allowed.
  • execTrigger function
  • Time dependencies
  • Facility to test schedule criteria for the current year
  • External job synchronization
Note: For the server to adjust the time, you must state the time in the schedule criteria explicitly (for example, 2:30 SUNDAY, but not EVERY 35 MINUTES).

The server does not adjust the times for the following to 3:00 a.m. if they fall in the spring-forward transition period:

  • Event simulation of jobs with time dependencies
  • Event simulation for future years
  • genTime function
  • Event listing
  • Forecasting
  • Facility to test schedule criteria for future years
Note: When the schedule criteria takes the form EVERY [N] MINUTES, the server does not adjust the time for the spring-forward transition period. For example, if NOW is 00:00 a.m. on the day spring forward occurs, EVERY 35 MINUTES schedules the Event at 12:35 a.m., 1:10 a.m., 1:45 a.m., 3:15 a.m., 3:50 a.m., and so on. In this case, the 2:15 a.m. scheduled time occurs at 3:15 a.m., not at 3:00 a.m.

Fall-Backward Adjustments

In the North American Eastern Standard Time Zone, DST ends on the first Sunday of November at 2:00 a.m.; the time falls back one hour to 1:00 a.m. The following illustration displays DST fallback:

This illustration displays DST fallback.

Events that are scheduled during the fall-back transition period (1:00 a.m. to 2:00 a.m. time period on the day fall back occurs) will not run twice. For example, on the day fall back occurs, 1:15 a.m. occurs twice spaced one hour apart. The first time, 1:15 a.m. occurs on the DST scale; the second time, 1:15 a.m. occurs on the EST scale. Events always run during the second time interval (Standard scale). In this case, the Event runs at 1:15 a.m. EST.

For example, at 12:40 a.m. on November 4, 2007, you define an Event with a schedule criteria of HOURLY. At 1:59:59 a.m. DST, the time falls back to 1:00 a.m. EST. The server triggers the Event at 1:00 a.m. EST, not one hour earlier at 1:00 a.m. DST.

Note: You can simulate your Applications and generate a forecast report for the day fall back occurs to find out which jobs run and when Events are scheduled on that day.
Additional Information:

DE supports daylight saving change so would not expect any issue but it’s good to know the following;

1.      The DE behavior and limitation with respect to workload processing as in the docs;

https://docops.ca.com/ca-wla-de/11-3-3/en/scheduling/schedule-criteria#ScheduleCriteria-DaylightSavingTime

2.      Schedule criteria of the form ‘every <n> minutes’ for example, ‘every 30 minutes’ should be stated explicitly.

Note: For the server to adjust the time, you must state the time in the schedule criteria explicitly (for example, 2:30 SUNDAY, but not EVERY 35 MINUTES).

3.      DE should  be updated with the latest 11.3 SP3 patch as there iss a fix related to daylight savings time;

Server Ignores Daylight Saving Time for ETZ or MTZ

4. If you have a problem with DST  In most cases, a simple fix is uusing dSeries 'Define' perspective re-upload the events in question.
It should push the workload to go or to run the SCHEDULEALLEVENTS CLI command to re-evaluate and re-schedule all events with schedule criteria define.