Time Zone Object (TZ)

Time definitions play a key role when programs communicate with each other, tasks are activated, conditions evaluated, data is saved, etc. They are even more important when Automic solutions are used on a global basis across several time zones in which interconnected tasks must run. Time Zone objects can be applied to multiple objects and purposes; this topic provides an overview of Time Zone objects, explains where you can apply them and indicates which Time Zone is used if you do not assign a Time Zone to an object

Object Definition

This topic provides information on the following:

Overview

All Automic components, such as server processes, agents, database, etc., use the standard UTC. Therefore, when you define a Schedule, Event, Script, etc., UTC is the default time that the system will use unless you create Time Zone objects and apply them accordingly.

The Time Zone (TZ) object takes care of the following two aspects:

The default time zone is defined in Client 0 and is therefore available system-wide. Administrators can add further Time Zone objects either in client 0 or in the individual clients. Furthermore, time zones can be assigned to user objects.

Basically, the most specific definition applies, that is, the time zone assigned to the user overrides the one assigned to the corresponding client and this one, in turn, overrules the time zone defined in client 0.

If no specific time zone is specified, the default is UTC.

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

Defining Time Zones

The steps for defining Time Zone objects (TZ) are the same as for any other Automic object. This section describes the settings that are specific to only Time Zone objects. For general information about the purpose of a time zone, see Time Zone Object (TZ).

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

Schedule Object

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.

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:

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.

XXX

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:

XXX

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.

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:

Important Considerations

See also:

Examples of Time Zone Definitions