Inside Automation Engine > Date and Time > Changing From Normal Time to Daylight Savings Time

Changing from Standard Time to Daylight Savings Time

The components (such as server processes, agents, databaseA database is an organized collection of data including relevant data structures.) internally use the internationally valid and precise UTC time scale. You can create TimeZone objects in order to have local times displayed and use them in task and script elements.

Standard Time and Daylight Savings Time

You can specify the point in time for changing from winter to summer time in a TimeZone object. The following illustration shows the relevant section in the Attributes tab.

When you change over from standard time (winter time) to daylight savings time (summer time), the clock is set forward by a particular number of minutes. The time difference from standard time to daylight savings time is country specific. Usually, a value of 60 minutes (one hour) is used. Setting the clock forward means that on the day on which you change over to the new daylight savings time, you lose one hour. This day is then one hour shorter than a regular day.

For example:

The local time is set forward for 60 minutes from 02:00:00 to 03:00:00. As a result, this day has only 23 hours and there is no local time between 02:00:01 and 02:59:59.

Consequences:

All scheduled tasks are processed, regardless of a clock change. Despite the fact that an hour is missing, a task that has been scheduled for 02:30 is processed, for example.
If two tasks have been scheduled - one at 02:30, the other one at 03:30 - they are processed with a time difference of only half an hour.

Changing from Daylight Savings Time to Standard Time

When you change over from daylight savings time to standard time (winter time), the clock is set back. Therefore, the time difference between the point when the time is set back and the newly set winter time is doubled. This day is then longer than a regular day.

For example:

The local time is set back for 60 minutes from 03:00:00 to 02:00:00. As a result, this day has 25 hours and the time between 02:00:01 to 02:59:59 is doubled.

Consequences:

The AE system notices that a task that is scheduled for 02:30 has already been processed. Therefore, it is not executed for a second time.
If two tasks have been scheduled - one at 02:30, the other one at 03:30 - they are processed with a time difference of two hours.

Event objects

The interval for event activation is not synchronized with time zones. For example, if an Event object should be triggered every 4 hours, a clock change to daylight savings time has the following impacts (time indicated in 24 hours):

Start time: 08:00
Additional triggering times: 12:00, 16:00, 20:00, 00:00, 04:00, 08:00
Clock change to daylight savings time: ..., 20:00, 00:00, 05:00, 09:00, 13:00

05:00 because the clock is set forward when it is changed to daylight savings time (at 02:00 to 03:00 o'clock), but the object still keeps its 4-hour interval. The same applies when you change over to standard time.

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 outside of the specified time frame after the clock has been changed. Automic recommends starting the Event object via a Schedule in order to avoid such a situation. The event's start time is then adjusted to summer or winter time when the period turnaround takes place.

When you set up an interval where the object would be executed in the hour that is missed out by the time change, the object will be executed at the next full hour.
Example: An interval of 20 minutes has been set, the first check time is 01:49, then the next check time should be 02:09. But since that hour is missing because of the time change, your object will be executed at 03:00. So the interval would be 11 minutes long only in this one instance.
The reason for this behavior is the necessity for the EH_NEXTCHECK to re-calculate UTC into local time (of client or object, respectively), in order to ensure that e.g. workflow or calender objects with time settings are executed correctly.