Change the scheduling time zone

Impact 1: Node scheduling time

The scheduled time for a node changes based on the new scheduling time zone. In the Schedule settings, assume Instance Generation Method is T+1 (Next Day), Schedule Type is Normal, Recurrence is Daily, and Scheduled Time is 00:01, which corresponds to the cron expression 00 01 00 * * ?. Also assume Rerun Property is Rerun allowed after success or failure and Effective Date is from 1970-01-01 to 9999-01-01.

Impact 2: Node time parameter configuration

Scheduling parameters replace variables in your code based on task-related times, such as the scheduled time and data timestamp. The values of these parameters change according to the new scheduling time zone.

YYYYMMDD=${yyyymmdd} LAST_2D=${yyyymmdd-2}

In the Parameters section, enter the scheduling parameters. Separate multiple parameters with spaces, for example, YYYYMMDD=${yyyymmdd} LAST_2D=${yyyymmdd-2}. These parameters take effect during periodic scheduling. You can use the smoke testing feature in the development environment to verify correct parameter replacement.

Impact 3: Time-related logic in node code

Variables in your code are parsed either by the gateway or by the compute engine. The parsing logic is as follows:

• If parsed by the gateway, the values change according to the new scheduling time zone. In scheduling scenarios (excluding ad hoc runs in Data Development), if you execute a command to get the time in a DataWorks script task, such as a Shell or pyodps node, by running the date command in a Shell node, the system returns the time based on your scheduling time zone.

• If parsed by the underlying compute engine, the engine's own time zone conversion rules apply. For details, see the documentation for the specific engine.

In the following code example, the time variables in the code are replaced with specific time strings based on the scheduled time and then passed to Hive. The actual time represented depends on the parsing logic of the Hive server.

if [ "${YYYYMMDDHH}" = "${YYYYMMDD}00" ] ;then
    echo '######## run hive reload data'
    hive --hiveconf hive.merge.tezfiles=false --hiveconf tez.queue.name=${YARN_QUEUE} -d YYYYMMDD=${LASTDAY} -d YYYYMMDDHH=${YYYYMMDDHH}  -d LASTDAY=${LAST_2D}
...

Impact 4: Baseline or alert times

Times related to baselines or alerts change according to the new scheduling time zone.

Impact 5: API-related times

Times related to APIs change according to the new scheduling time zone.

Impact 6: Time zones of underlying engines

The time zones of underlying engines, such as Data Integration and MaxCompute, are set by each engine and are independent of the DataWorks scheduling time zone. Scheduling parameter values are passed to the engine as plain strings and processed according to the engine's own rules. For information about how engines handle time zones, see the documentation for the respective engine.

Scenario 1: New tenant, first workspace

When a new user creates their first workspace in a region that supports time zone changes, a dialog box informs you that the scheduling time zone can be changed to a non-local one. To make the change, you must submit a ticket to contact technical support. You can decide whether to request the change based on your business needs and the information in Precautions.

Scenario 2: Existing tenants

If you have existing workspaces in a region that supports time zone changes and need to change the scheduling time zone to a non-local one, you also need to submit a ticket to contact technical support. Since this involves migrating existing data, such as nodes and instances, it may affect your workloads. We recommend performing a thorough evaluation. The process involves the following steps:

1. Your side: Assess the impact on existing data.

2. Platform side: Migrate existing data.

3. Platform side: Set the new time zone.

4. Your side: Restore existing data and verify the new time zone.

   We recommend running multiple verification tests for each task type.

Method 1: Check Schedule settings

After the time zone setting takes effect, a blue notification message "The scheduling time zone is UTC" appears at the top of the Schedule > Scheduling Time tab.

1. Log on to the DataWorks console. In the target region, click Data Development and O&M > Data Development in the left-side navigation pane. Select a workspace from the drop-down list and click Go to Data Development.

2. Click to open an existing node in Data Development or create a new node to go to the node editing page.

3. On the node editing page, click the Scheduling Settings > Data Timestamp tab to check if the new time zone setting has taken effect.

Method 2: Check in Operation Center

Log on to the DataWorks console. After you switch to the target region, choose Data Development and O&M > Operation Center in the left-side navigation pane. Select the desired workspace from the drop-down list and click Operation Center. The current time zone configuration is displayed in the notification bar at the top of the Operation Center page.

For example, if the scheduling time zone is set to UTC, the notification bar displays This tenant uses UTC as the scheduling time zone. Operation Center displays time in this time zone by default.