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
Object class: System object
Object type/Short form: TZ
Default object templates:
- CET (Central European Time)
- CST (Central Standard Time
- EST (Eastern Standard Time)
- GMT (Greenwich Mean Time)
- MST (Mountain Standard Time)
- PST (Pacific Standard Time)
- SYD
- TZ
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 translation of UTC into local time, which is displayed in the user interface and that can be used in tasks, script elements, etc. Conversely, it also converts the time in which an operation has been performed into the internal UTC.
- The calculation of time changes due to switches to Daylight Saving Time or Standard Time. This is essential, as UTC does not consider Daylight Saving Time changes.
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.
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:
- Standard pages that are always available, no matter what type of object you are defining:
- The object-specific page described here.
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.
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:
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.
You can assign Time Zone objects to Clients, Users, Queues, Scripts and executable objects. For all objects, the following applies:
- When you assign a Time Zone to an object, this one applies and overrules the Time Zone objects assigned to the Client and to Client 0 (if available).
- If you do not assign a Time Zone to an object, the one defined in the Client applies.
- If no Time Zone is assigned to the Client, the one defined in Client 0 applies.
- If no Time Zone is defined in Client 0, UTC applies.
Important Considerations
- Tasks in Workflows use the Time Zone defined in the Workflow unless you assign them a specific one in the Time & Dependencies properties tab.
- Tasks in Schedules use Time Zone defined in the Schedule
Time Zones are used in many script elements. In the following ones, Time Zones are assigned as parameters:
- CONV_TIMESTAMP
Converts date and time for use in another time zone - SYS_DATE
Returns the current date at the beginning of the script processing - SYS_DATE_PHYSICAL
Returns the current date - SYS_TIME
Returns the current time of day at the beginning of the script processing - SYS_TIME_PHYSICAL
Determines the current time of day - SYS_TIMESTAMP_PHYSICAL
Provides current date and time
- CONV_TIMESTAMP
See also: