Time Zone (TZ)

Time definitions play a key role when programs communicate with each other, tasks are activated, conditions are evaluated, data is saved, and so forth. They are even more important when an Automation Engine system is used on a global basis across several time zones in which interconnected tasks must run. All Continuous Delivery Automation components use the standard UTC. This is also the default time applied to an object when you create it unless you assign it a Time Zone object. The default Time Zone is defined in Client 0 and is available system-wide. As a system administrator, you can add further Time Zone objects either in Client 0 or in the individual Clients. As a developer and object designer, you assign the available Time Zone objects to the objects you create.

Time Zone (TZ) objects take care of the following:

Important! The name of Time Zone objects cannot be longer than 8 characters.

Object class: System object

Object type/Short form: TZ

Default object templates:

This page includes the following:

Defining Time Zone Objects

A Time Zone object definition is made up of the following pages:

Important! In the Daylight Saving Settings section you indicate if the Time Zone object will take the Daylight Savings Time shift into account. If this time shift affects any of your Clients because it is located in a country that observes this change and you DO NOT activate this option, tasks that are scheduled to be processed at the time the shift takes place will return an error.

Applying a Year to a Time Zone

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

Example:

A Time Zone object contains the settings for changing from standard to daylight saving time. The government of the country to which this applies decides to stop applying these time changes. This decision will take effect in two years. You can create the Time Zone object and set Apply from Year in two years from now.

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

Daylight Saving and Standard Time Changes

As an administrator user in charge of defining the Time Zone objects, to make sure that the processes always run accurately despite the shifts between Daylight Saving Time and Standard Time, you activate and configure the Define Daylight Saving Time option in the Time Zone object definition.

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 activate this option and configure it correctly, this is taken into account in all objects to which the Time Zone is assigned.

Changing from Standard to Daylight Saving Time

You specify that the clock will be set 60 minutes forward at 02:00:00 on the 5th Sunday in March.

Note: If the defined month does not include 5 Sundays, the definition 5th Sunday refers to the last weekday of this month.

Screenshot of the parameters in the Daylight Saving Setting section in a Time Zone object.

This means that an hour is missing between 02:00:01 and 2:59:59. By activating this option all scheduled tasks are processed as usual, also 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

You specify that he clock will be set 60 minutes backward at 02:00:00 on the 1st Sunday in November:

Screenshot of the parameters that revert the settings

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.

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 120 minutes.

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.

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 Sunday in March. In this case, the event will be executed at the next full hour, which in our example would be 03:00:00.

Important! 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. Start the Event object via a Schedule to avoid such a situation. The Event start time is then adjusted to Daylight Time or Standard Time when the period turnaround takes place.

Using Time Zone Objects

You can assign Time Zone objects to Clients, Users, Queues, Scripts and executable objects. For all objects, the following applies:

Notes:

See also: