Daylight Saving and Standard Time Changes

Shifts between Daylight Saving Time and Standard Time are not considered by the UTC standard. Therefore, to make sure that your processes always run accurately, you must define them in the time zone that you assign to other objects and/or tasks.

This has important consequences for scheduled tasks, workflows, etc.

Usually, the local time is set forward or backward by one hour at 02:00:00. This means that either there exists no local time between 02:00:01 and 2:59:59 or that it is duplicated. In any case, if you define the appropriate settings here, this is taken into account in all objects to which this time zone has been assigned.

Applying a Year to a Time Zone

In the General Settings sections, Time Zone objects can store different specifications for individual years. This function facilitates the integration of date modifications.

Warning! It is also possible to adjust a Time Zone object in the year in which the date will be changed. In doing so, the object's statistical records of previous years would be affected as they would show wrong values because they use the new specifications made for the Time Zone object.

Changing from Standard to Daylight Saving Time

Let's suppose that you have specified that the clock will be set 60 minutes forward at 02:00:00 on the 5th Sunday in March.

The 5th weekday of a month always refers to the last weekday of this month even if there is no 5th occurrence of this day.

This means that an hour is missing between 02:00:01 and 2:59:59. However, all scheduled tasks are processed as usual, even those that have been scheduled for 02:30:00 for example.

Likewise, two connected tasks have been scheduled with an hour difference, let's say one at 02:30:00 and the other at 03:30:00, are also processed regardless of the hour and with a time difference of 30 minutes.

Changing from Daylight Saving to Standard Time

Let's suppose that you have specified that he clock will be set 60 minutes backward at 02:00:00 on the 1st Sunday in November:

This means that the local time between 02:00:01 and 2:59:59 is duplicated. A task that has been scheduled for 02:30:00 is not processed twice, since the system knows that it has already been processed.

Event Objects Behavior with Time Changes

Time changes also have an impact on events that are triggered at regular intervals. The event activation is not synchronized with the time zone object definitions.

For example, an event is triggered every 4 hours starting at 08:00. This means that the additional triggering times are 12:00, 16:00, 20:00, 00:00, 04:00, 08:00, and so on.

On the 5th Sunday in March the clock is set one hour ahead at 02:00:00. Therefore, the additional triggering times will be 12:00, 16:00, 20:00, 00:00, 05:00, 09:00, 13:00, etc. That is, the 4-hour interval is still kept, as an hour is missing between 00:00 and 05:00.

Now suppose that the interval for triggering the event is so defined that it should be executed at 02:30:00 on the 5th of March. In this case, the event will be executed at the next full hour, which in our example would be 03:00:00.

Pay special attention to this behavior if a calendar with a time period has been defined in the Event object. In this case, the triggering times are re-scheduled and can lie within or without the specified time frame after the time has been changed.
Automic recommends starting the Event object via a Schedule in order to avoid such a situation. The event start time is then adjusted to Daylight Time or Standard Time when the period turnaround takes place.