Time Zones

By default, SMART folders and jobs run and execute in the time zone where the Control-M/Server is located. You can change the time zone where your SMART folders and jobs run and execute in the scheduling criteria, as described in Scheduling. You can also define Site Standard rules with time zones, as described in Creating a Site Standard Rule.

Jobs that are scheduled to run in a user-defined time zone must be saved at least 48 hours before their intended execution dates. Jobs defined with different time zones must not be combined in the same folder. This ensures that the jobs automatically run via the appropriate New Day procedure or User Daily method. If a newly scheduled job has to run today, you must run it manually. For more information on New Day and User Daily, see New Day Procedure.

Daylight-Savings Time

Daylight-savings time (DST) refers to the spring, summer, and early fall season when clocks are set ahead a half hour, hour, or more to add daylight hours to the beginning of the work day. If automatic time zone management is not configured, you must manually accommodate for DST every year, as described in Defining Daylight-Savings Time.

After you define DST, you must take the following considerations into account:

Time Zone Utilities

In the ctmpsm Monitoring utility, job state (STATE) values are calculated according to the Control-M/Server New Day time.

The Control-M/Server resides in a PST (GMT-08:00) time zone and executes the New Day procedure at midnight. The Payroll_EST job is scheduled to run on 6 July in the EST (GMT-05:00) time zone. The following job STATE values appear in the ctmpsm utility, at these times:

  • 5 July, midnight–21:00 pm PST: The job STATE value in the ctmpsm utility is Wait ODAT.

  • 5 July, 21:00 pm PST–6 July, 21:00 pm PST: The job STATE value in the ctmpsm utility begins as Wait Sched and changes depending upon the prerequisites. After the prerequisites are met, the job STATE changes in the following order:
    SubmittedExecutingEndedAnalyzedPost Proc.

  • 6 July, 21:00 pm–midnight PST: The job STATE value in the ctmpsm utility is Post ODAT.

For more information on job STATE values, see Values in the STATE and STATUS ctmpsm Fields.

To run jobs in a specific time zone on a future date in the CLI, see the -odate and -odate_option parameters in any of the following Monitoring utilities:

Adding a Time Zone

This procedure describes how to add a new time zone to the TimeZone.dat file, which enables you to define a time zone in the scheduling criteria for a SMART folder, sub-folder, or job.

Begin

  1. Navigate to the following directories, and complete steps 2–4 of this procedure for each TimeZone.dat file:

    • UNIX

      • Control-M/EM Server: <Control-M/EM_home>/ctm_em/etc/cli/data

      • Control-M/Server: <Control-M/Server_home>/ctm_server/data

    • Windows

      • Control-M/EM Server: <Control-M/EM_home>\Default\Data

      • Control-M/Server: <Control-M/Server_home>\ctm_server\data

      • Control-M Client: <Control-M_Client_home>\data

  2. Open the TimeZone.dat file in a text editor.

    The list of currently defined time zones appears, in the following format:

    <Time_Zone> (GMT±<hh:mm>)

    where the Time_Zone parameter represents the time zone ID.

    The label RIO represents the Rio de Janeiro time zone, and its time zone is defined in the TimeZone.dat file as RIO (GMT-03:00).

  3. Add a new time zone to the end of the list in the standard time zone format.

    • PTI (GMT-08:00) for the Pitcairn Islands, British Overseas Territories.

    • DAR (GMT+09:30) for Darwin, Australia.

  4. Verify that there is an empty line at the end of the file, and then save and close the file.

  5. After you have added the new time zone to each TimeZone.dat file, run the following command on the following components:

    • UNIX

      • Control-M/EM Server: "<EM_Home>/bin/em bmcpython <EM_Home>/etc/cli/data/convert_timezone_dat_to_json.py" "<EM_Home>/etc/cli/data/TimeZone.dat" "<EM_Home>/etc/cli/data/TimeZone.json"

      • Control-M/Server: run_python "<CTM_Server_Home>/ctm_server/scripts/convert_timezone_dat_to_json.py" "<CTM_Server_Home>/data/TimeZone.dat" "<CTM_Server_Home>/data/TimeZone.json"

    • Windows

      • Control-M/EM Server: "<EM_Home>\bin\em bmcpython <EM_Home>\etc\cli\data\convert_timezone_dat_to_json.py" "<EM_Home>\etc\cli\data\TimeZone.dat" "<EM_Home>\etc\cli\data\TimeZone.json"

      • Control-M/Server: run_python "<CTM_Server_Home>\ctm_server\scripts\convert_timezone_dat_to_json.py" "<CTM_Server_Home>\data\TimeZone.dat" "<CTM_Server_Home>\data\TimeZone.json"

  6. Do the following:

    1. Refresh the Control-M/EM server.
    2. Refresh the Control-M/Server.

    3. Log out and then log back in to Control-M client.

Defining Daylight-Savings Time

This procedure describes how to define daylight-savings time (DST) for time zones in the TimeZone.dat file. You must perform this procedure only in the following situations:

  • The Control-M/Server resides in a location that uses DST.

  • The SMART folder, sub-folder, or job scheduling criteria rely on a time zone with a DST that differs from the Control-M/Server time zone.

  • You have not configured automatic time zone management, as described in Time Zones.

In any of the above instances, you must change the DST definitions yearly, since the dates when the clocks are changed shift every year.

Begin

  1. Navigate to the following directories, open the TimeZone.dat file in a text editor, and complete steps 2–4 of this procedure for each file.

    • UNIX

      • Control-M/EM Server: <EM_Home>/ctm_em/data

      • Control-M/Server: <Control-M/Server_Home>/data

      • Control-M Client: <Control-M_Client_Home>/data

    • Windows

      • Control-M/EM Server: <EM_Home>\ctm_em\data

      • Control-M/Server: <Control-M/Server_Home>\data

      • Control-M Client: <Control-M_Client_Home>\data

    The list of currently defined time zones appears in the following format:

    <Time_Zone> (GMT±<hh:mm>)

    where the Time_Zone parameter represents the time zone label.

    The label EST represents the Eastern Standard Time time zone, which is defined in the TimeZone.dat file as EST (GMT-05:00).

  2. Do one of the following, based upon the relevant hemisphere:

    • Northern Hemisphere: Define the relevant time zone definition in the TimeZone.dat file so that it includes DST adjustments, as follows:

      <Time_Zone> (GMT±<hh:mm>) FROM <dd.mm hh:mm> TO <dd.mm hh:mm> (GMT±<hh:mm>)

      For more information, see Northern Hemisphere DST Parameters.

    • Southern Hemisphere: Define the relevant time zone definition in the TimeZone.dat file so that it includes DST adjustments, as follows:

      <Time_Zone> (GMT±<hh:mm>) FROM <dd.mm hh:mm> TO <dd.mm hh:mm> (GMT±<hh:mm>)

      For more information, see Southern Hemisphere DST Parameters.

    • In the Southern Hemisphere, the syntax and type of time frame (standard time instead of DST) is reversed.

    • If a relevant time zone contains several countries, and some observe DST and some do not, or if they change the clock on different days, add additional time zone definitions to cover the variations.

  3. Verify that there is an empty line at the end of the file, then save and close the file.

  4. After you have added the new time zone to each TimeZone.dat file, run the following command on the following components:

    • UNIX

      • Control-M/EM Server: "<EM_Home>/bin/em bmcpython <EM_Home>/etc/cli/data/convert_timezone_dat_to_json.py" "<EM_Home>/etc/cli/data/TimeZone.dat" "<EM_Home>/etc/cli/data/TimeZone.json"

      • Control-M/Server: run_python "<CTM_Server_Home>/ctm_server/scripts/convert_timezone_dat_to_json.py" "<CTM_Server_Home>/data/TimeZone.dat" "<CTM_Server_Home>/data/TimeZone.json"

    • Windows

      • Control-M/EM Server: "<EM_Home>\bin\em bmcpython <EM_Home>\etc\cli\data\convert_timezone_dat_to_json.py" "<EM_Home>\etc\cli\data\TimeZone.dat" "<EM_Home>\etc\cli\data\TimeZone.json"

      • Control-M/Server: run_python "<CTM_Server_Home>\ctm_server\scripts\convert_timezone_dat_to_json.py" "<CTM_Server_Home>\data\TimeZone.dat" "<CTM_Server_Home>\data\TimeZone.json"

  5. Do the following:

    1. Refresh the Control-M/EM server.
    2. Refresh the Control-M/Server.

    3. Log out and then log back in to Control-M client.

  6. Update the relevant scheduling criteria in the relevant job definitions and Site Standards with the new time zone definitions.

    If you delete or modify a time zone definition in the TimeZone.dat files, you must change any Site Standards and job definitions that specify the changed time zone. Otherwise, those job definitions are invalid.

Northern Hemisphere DST Parameters

The following table describes the parameters that enable you to add or modify Northern Hemisphere DST definitions in the TimeZone.dat file, as described in Defining Daylight-Savings Time.

Parameter

Description

<Time_Zone>

Defines the standard time zone name.

ANC defines the time zone for Anchorage, Alaska, USA.

The First (GMT±<hh:mm>)

Defines the standard time zone in Greenwich Mean Time (GMT) offset format, as follows: 

  • hh: Hours

  • mm: Minutes

(GMT-09:00) defines the standard time zone as nine hours west of GMT.

FROM <dd.mm hh:mm>

Defines the day and time that DST begins, in days (dd) of the month (mm) and hours (hh) and minutes (mm) of the day.

FROM 12.03 02:00 indicates that DST begins on 12 February at 02:00 am.

TO <dd.mm hh:mm>

Defines the day and time that DST ends, in days (dd) of the month (mm) and hours (hh) and minutes (mm) of the day.

TO 05.11 02:00 indicates that DST ends on 5 November at 02:00am.

The Second (GMT±<hh:mm>)

Defines the DST time zone in Greenwich Mean Time (GMT) offset format, as follows: 

  • hh: Hours

  • mm: Minutes

(GMT-08:00) defines the DST time zone as eight hours west of GMT.

Bill needs to define DST support for Anchorage, Alaska, USA. The current entry for Anchorage in each TimeZone.dat file is ANC (GMT-09:00). Anchorage DST begins on 12 March 2023 at 02:00 am and ends on 5 November 2023 at 02:00 am. Bill changes the entry to define DST support for Anchorage, as follows:
ANC (GMT-09:00) FROM 12.03 02:00 TO 05.11 02:00 (GMT-08:00)

Southern Hemisphere DST Parameters

The following table describes the parameters that enable you to add or modify Southern Hemisphere DST definitions in the TimeZone.dat file, as described in Defining Daylight-Savings Time.

In the Southern Hemisphere, the syntax and type of time frame (standard time instead of DST) is the reverse of the Northern Hemisphere definitions.

Parameter

Description

<Time_Zone>

Defines the standard time zone name.

SYD defines the time zone for Sydney, Australia.

The First (GMT±<hh:mm>)

Defines the DST time zone in Greenwich Mean Time (GMT) offset format, as follows: 

  • hh: Hours

  • mm: Minutes

(GMT+11:00) defines the DST time zone as 11 hours east of GMT.

FROM <dd.mm hh:mm>

Defines the day and time that standard time begins, in days (dd) of the month (mm) and hours (hh) and minutes (mm) of the day.

FROM 02.04 03:00 indicates that standard time begins on 2 April at 03:00am.

TO <dd.mm hh:mm>

Defines the day and time that standard time ends, in days (dd) of the month (mm) and hours (hh) and minutes (mm) of the day.

TO 01.10 02:00 indicates that standard time ends on 1 October at 02:00am.

The Second (GMT±<hh:mm>)

Defines the standard time zone in Greenwich Mean Time (GMT) offset format, as follows: 

  • hh: Hours

  • mm: Minutes

(GMT+10:00) defines the standard time zone as 10 hours east of GMT.

Susan knows that in the Northern Hemisphere, during spring and summer, time zone definitions are set to DST where it is used. At the same time in the Southern Hemisphere, where it is fall and winter, locations that use DST are set to standard time. In Sydney, Australia, standard time (GMT+10:00) lasts from 2 April 2023 at 03:00 am to 1 October 2023 at 02:00 am. The rest of the year, the time zone is set to DST for spring and summer, which is one hour later (GMT+11:00). Susan changes the current entry to define DST support for Sydney, as follows:
SYD (GMT+11:00) FROM 02.04 03:00 TO 01.10 02:00 (GMT+10:00)

Daylight-Savings Time Considerations

If your data center includes multiple time zones, you might need to adjust the TimeZone.dat files to reflect the different daylight-savings time (DST) offsets in those time zones. This adjustment is especially important because the dates that the clocks are changed in each time zone often differ from each other, in addition to being different from themselves in previous and subsequent years.

The following examples illustrate other important considerations you must take into account when you define DST.

At 02:00am, the clock advances one hour (02:00 am becomes 03:00 am). If the host operating system automatically adjusts the clock without restarting the system, do not shut down Control-M when the clock is being advanced.

  • New DayClosed A Control-M process that begins every day at 7:00 AM, adds jobs and folders to the Run Queue for the day that is about to begin, and removes jobs and folders from previous days. Procedure

    • If the New Day procedure begins before you the clock is advanced, the New Day procedure begins beforehand and continues normally, even if the clock is advanced while the New Day procedure is in progress.

    • If the New Day procedure is scheduled to begin at exactly 02:00 am, the same considerations apply. It is possible that the New Day procedure will begin execution before the clock is manually changed. Otherwise, if you manually change the clock, this starts the New Day procedure.

    • If the New Day procedure is scheduled to begin between 02:00 am and 03:00 am, after the host clock is advanced, Control-M starts the normal New Day procedure.

    • If the New Day procedure is scheduled to begin after 03:00 am, no action is required. Control-M starts the standard New Day procedure.

  • Time-Dependent Notifications

    • Notifications that are scheduled to be sent before 02:00 am do not require any action.

    • Notifications that are scheduled to be sent between 02:00 am and 03:00 am are issued, even though there might not be a delay in production because the time frame for production is smaller.

    • The above information also applies to jobs that have notifications that are scheduled for later, such as at 06:00 am). These jobs might be considered late because of the tighter production time frame.

  • Time-Dependent Schedules

    • From and To: Jobs that are scheduled to run during times that overlap the time gap that is created by the one-hour advancement might require manual intervention. For example, it is possible that a job with a From value in its scheduling criteria of 02:15 am and a To value of 02:45 am might not run at all. These jobs must be manually adjusted.

    • cyclicClosed A SMART folder or job that executes multiple times in one run, whether for specific intervals, sequences of intervals, or times. Jobs or SMART Folders: The next run of cyclic jobs with an interval that exceeds one hour runs one hour sooner than originally scheduled. Cyclic jobs with an interval that is less than one hour run immediately. A cyclic job might have to be deleted and then run again to continue the processing cycle for the current day.

  • Control-M/Server Log File: The Control-M/Server log file does not contain entries with timestamps between 02:00am and 03:00am. Any scripts or programs that rely on log entry times must be checked for possible discrepancies when the host clock is advanced.

Standard Time Considerations

The following examples illustrate important considerations you must take into account when the clock is moved back (manually or automatically) from DST to standard time.

At 02:00am the clock retrogresses one hour (02:00 am becomes 01:00 am).

  • New DayClosed A Control-M process that begins every day at 7:00 AM, adds jobs and folders to the Run Queue for the day that is about to begin, and removes jobs and folders from previous days. Procedure

    • If the New Day procedure begins before 01:00 am, no special action is required. The New Day procedure runs only once, between midnight (00:00) and 00:59 am.

    • If the New Day procedure begins at exactly 01:00 am, you must not turn back the host clock to 01:00 am, to avoid another New Day procedure. A second New Day procedure requires manual intervention. BMC recommends that you wait until 02:01 am to turn the clock back to 01:01 am.

    • If the New Day procedure is scheduled to begin between 01:00 am and 02:00 am, one of the following actions must be performed:

      • Wait at least a full hour after the New Day procedure begins until to ensure it has ended, and then turn the clock back as required.

      • Update the clock before New Day procedure begins.

      For example, if the New Day procedure begins at 01:45 am, the host clock must be moved back one hour by no later than 01:44 am. If the clock is not moved back by 01:44 am, you must wait until 02:46 am to change the time.

    • If the New Day procedure begins after 02:00 am, no special action is required.

  • Time-Dependent Notifications: Notifications that are scheduled to be sent between 01:00 am and 02:00 am might be issued twice.

  • Time-Dependent Schedules

    • From and To: No special action must be taken for jobs with From–To scheduling criteria. Jobs scheduled to begin execution between 01:00 am and 02:00 am begin to execute the first time that this interval occurs if their prerequisites, Lock Resources, and Resource Pools are met. These jobs can also be restarted after the clock is moved back.

    • Cyclic Jobs or SMART Folders: The next run of cyclic jobs runs one hour later than scheduled.

  • Control-M/Server Log File: The Control-M/Server log file might contain entries with timestamps that are earlier than previous entries, due to the one-hour retrogression. The same considerations that apply to DST also apply to standard time.