Procedures to implement Mexico timezone change (No DST) in AutoSys Environments
search cancel

Procedures to implement Mexico timezone change (No DST) in AutoSys Environments

book

Article ID: 263610

calendar_today

Updated On:

Products

CA Workload Automation AE - Scheduler (AutoSys)

Issue/Introduction

As a result of an order issued by the Mexican Government on October 26th, 2022, the United Mexican States will no longer observe Daylight Saving Time (DST) from the calendar year 2023.
The following procedures required to be implemented in all the AutoSys instances running in Mexico time zones to comply with the notification.

Environment

This procedure is strictly for environments running within or utilizing Mexico's time zones that have to be transitioned from Daylight Saving Time (DST) to Standard Time (no DST).

Resolution

01. Windows Operating System:
==========================

After applying the Microsoft Mexico 2023 time zone update at the O/S level, follow this procedure for AutoSys components (Scheduler, Application Server, WebServer services) running on a Windows machine with Windows server operating system time zone set to Mexico time zones:

Note: Below steps (1,2) are not applicable for AutoSys release 11.3.6.

1.  Download the latest *.res files from the below ICU open source link, and copy them to %AUTOSYS% directory:

https://github.com/unicode-org/icu-data/tree/main/tzdata/icunew/2023c/44/le 


2.  Set the Windows SYSTEM environment variable by following the procedure below:

a. Right-click on the Windows icon located on the taskbar and select System.
b. In the Settings window, navigate to the Related Settings section and select Advanced system settings.
c. On the Advanced tab, click on the Environment Variables button.
d. Click the New button to create a new environment variable named ICU_TIMEZONE_FILES_DIR with the value "C:\Program Files\CA\Workload Automation AE\autosys" (Point it to the location of the downloaded files if they are copied to a different directory).
e. Click the Apply button, followed by the OK button to ensure the changes take effect.
f. Restart the Windows server.

3. Take a backup of the file: %AUTOSYS%\Win4TimezonesNewDSTRule.cfg and update the content of time zone tags for the Mexican time zones (GUADALAJARA and SASKATCHEWAN) as the following -

a. Find the time zone section and update it to be -

<TZ="GUADALAJARA, MONTERREY - NEW, MEXICOCITY">
"CST6"
360
"Central Standard Time (Mexico)"
0, 0, 0, 0, 0, 0, 0, 0
0
"Central Daylight Time (Mexico)"
0, 0, 0, 0, 0, 0, 0, 0
0
</TZ>

b. Remove the following tag from the file (This is no longer needed) 

<TZ="GUADALAJARA, MONTERREY - OLD">
"CST6CDT,M4.1.0,M10.5.0"
360
"Mexico Standard Time"
0, 10, 0, 5, 2, 0, 0, 0
0
"Mexico Daylight Time"
0, 4, 0, 1, 2, 0, 0, 0
-60
</TZ>

c. If the server time zone is set to Guadalajara, find the corresponding time zone tag for SASKATCHEWAN and move the section to be listed below the tag for GUADALAJARA .

(This is needed as the AutoSys services source the first one from the file during the startup as the time zone for both the cities is same. It is optional if the infrastructure is okay with services reading the time zone as "SASKATCHEWAN" instead of "Guadalajara")

The order should look like -

<TZ="GUADALAJARA, MONTERREY - NEW, MEXICOCITY">
"CST6"
360
"Central Standard Time (Mexico)"
0, 0, 0, 0, 0, 0, 0, 0
0
"Central Daylight Time (Mexico)"
0, 0, 0, 0, 0, 0, 0, 0
0
</TZ>


<TZ="SASKATCHEWAN, TEGUCIGALPA">
"CST6"
360
"Central America Standard Time"
0, 0, 0, 0, 0, 0, 0, 0
0
"Central America Standard Time"
0, 0, 0, 0, 0, 0, 0, 0
0
</TZ>

          4. The following database query needs to be executed against each database (incase of dual DB) of every AutoSys instance to honor NO DST change (for example: America/MexicoCity): 

           ORACLE:

                 update aedbadmin.ujo_timezones set zone='CST6' where name='America/MexicoCity';
        commit;

           OTHER Databases:

                 update ujo_timezones set zone='CST6' where name='America/MexicoCity'

The aforementioned database query needs to be executed even if the Autosys server is running outside Mexico timezone. However, a few jobs are configured to use it.

5. Restart all the AutoSys services

6. All the jobs that are configured to use 'America/MexicoCity' in the job definition needs to be reset (update_job: JobName) for their next runs to be rescheduled appropriately.

 

02. UNIX/LINUX Operating System:
============================

Follow the procedure is for AutoSys components (Scheduler, Application Server, WebServer services) running on a Unix/Linux machines. 

1. Apply the respective Operating System's timezone patch. 

2. If the AutoSys server running in Mexico time zones, then find the environment variable  "TZ" defined in the shell profile files(5) named as $AUTOUSER/"autosys.$SHELL.$HOSTNAME" files and update TZ value to reflect CST6 (TZ=CST6). 

         3. The following database query needs to be executed against each database (incase of dual) of every AutoSys instance to honor NO DST change (for example: America/MexicoCity): 

           ORACLE:

                 update aedbadmin.ujo_timezones set zone='CST6' where name='America/MexicoCity';
        commit;

           OTHER Databases:

                 update ujo_timezones set zone='CST6' where name='America/MexicoCity'

4. Restart all the Autosys Services.

5. All the jobs that are configured to use 'America/MexicoCity' in the job definition needs to be reset (update_job: JobName) for their next runs to be rescheduled appropriately.

 

Additional Information

AutoSys Workload Automation WebUI (WCC):

WebUI displaying incorrect time (+1 hour) in the user interface due to an erroneous DST change. The following patches are released to address the problem in the respective WebUI component release.

Solution for WebUI release 12.0.00 and 12.0.01:
 
Solution for WebUI release 12.1.00:

 

AutoSys Workload Automation Agents: 

Although this change will not affect the Workload Automation agents, it is worth noting that the timestamps recorded in the agent logs located in <AGENT_INSTALL_DIR>/log are one hour ahead of the server time zone, if the Agent machine is running in Mexico time zones. This can be resolved by upgrading the Java Runtime Environment (JRE) used by the agent, which can be found in <AGENT_INSTALL_DIR>/wla_jre, to the latest version of JRE8 (u362 or higher).