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 Automic 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:

• Translating UTC into the local time, which is displayed in the user interface and that can be used in tasks, script elements, etc.
• Converting the time in which an operation has been performed into the internal UTC.
• Calculating time changes due to switches to Daylight Saving Time or Standard Time. This is extremely important, as UTC does not consider Daylight Saving Time changes.

• 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

This page includes the following:

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

• Standard pages that are always available, no matter what type of object you are defining:
  • General Page
  • Documentation Page
• The object-specific page described here.

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.

As a developer and object designer, you assign Time Zone objects to executable objects on their Attributes page. Consider the following:

• Schedules and C_PERIOD objects

  When you assign a Time Zone object to a Schedule, all the start times that you specify for the tasks within the Schedule are the local times of the assigned time zone.

• Jobs

  The Time Zone assigned to a Job does not have an impact on the time on which the object is executed. Instead, it has an impact on the script functions that you use on its Process pages (for example, SYS_TIME or SYS_DATE).

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.

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.

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.

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, for example, also all tasks that have been scheduled for 02:30:00.

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.

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 01:00:01 and 01: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.

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.

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, UTC applies.
• If no Time Zone is defined in Client 0, UTC applies.

Notes:

• 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 ofs day
  • SYS_TIMESTAMP_PHYSICAL
    Provides current date and time