By default, DataWorks workspaces use the local time zone of the region where they reside. For global teams that coordinate pipelines across multiple regions, you can standardize all workspaces in a region to UTC+0 or UTC+8 — eliminating time-based conflicts and aligning scheduling logic across geographies. This topic explains which regions support the change, what gets affected, and how to request it.
This change is irreversible. Read the precautions below before proceeding.
Supported regions
The scheduling time zone is a region-level setting. When you change it, the new time zone applies to all workspaces in that region — not individual workspaces.
The following regions support switching to UTC+0 or UTC+8:
| Region | Switch to UTC+0 | Switch to UTC+8 |
|---|---|---|
| US (Silicon Valley) | Supported | Supported |
| US (Virginia) | Supported | Supported |
| Germany (Frankfurt) | Supported | Supported |
| Singapore | Supported | Supported (same as the local time zone) |
| China (Hong Kong) | Supported | Supported (same as the local time zone) |
| Japan (Tokyo) | Supported | Supported |
Precautions
Review these precautions before changing the scheduling time zone.
Irreversible operation
After the scheduling time zone is changed, it cannot be changed again. The change involves migrating historical data — including existing nodes and instances — which may disrupt running tasks. Assess the impact on your business before proceeding.
Region-level scope
The scheduling time zone is a region-level setting. The change affects all workspaces in the region simultaneously. There is no per-workspace override.
What changes and what doesn't
| Component | Affected? |
|---|---|
| Node scheduled time | Yes |
Node time parameter values (e.g., ${yyyymmdd}) |
Yes |
| Gateway-parsed variables in node code | Yes |
| Baselines and alerts | Yes |
| API time fields | Yes |
| DataStudio: run single node, run with parameters, ad hoc query | No — these don't use the scheduling system |
| DataStudio: run workflow, smoke testing | Yes — these use the scheduling system |
| Underlying compute engine time zone (e.g., MaxCompute, Data Integration) | No — engine time zones are independent |
Scheduling parameter values are sent to the compute engine as strings. The engine processes them according to its own time zone rules. Refer to the specific engine's documentation for details.
How the change affects your configuration
Node scheduling time
After the change, each node's scheduled time is recalculated based on the new scheduling time zone.
Node time parameter values
Scheduling parameters replace variables in node code using the task's scheduled time and data timestamp. After the change, these replacement values are calculated in the new time zone.
YYYYMMDD=${yyyymmdd} LAST_2D=${yyyymmdd-2}
Variables in node code
Variables in node code are parsed by two different components, each with different behavior:
-
Gateway-parsed variables — change according to the new scheduling time zone. For example, running the
datecommand in a Shell node returns the time based on the scheduling time zone. -
Compute engine-parsed variables — follow the engine's own time zone rules. Refer to the engine's documentation for details.
The following figure shows an example. In a scheduling scenario, the time variable in the code is replaced with a specific time string based on the scheduled time, then sent to Hive. The expressed time depends on the parsing logic on the Hive server.
Baselines and alerts
Baseline and alert times change based on the new scheduling time zone.
API time fields
Time fields returned by APIs change based on the new scheduling time zone.
Underlying engine time zone
The time zone of underlying engines — such as Data Integration and MaxCompute — is set by the engine itself and is independent of the DataWorks scheduling time zone. The change does not affect engine time zones.
For details on how Data Integration handles time zone differences, see Appendix: Handling time in Data Integration.
Request the change
The scheduling time zone change requires submitting a ticket to technical support. The process varies depending on whether you already have workspaces in the region.
New tenants
When you create your first workspace in a supported region, a pop-up asks whether you want to change the scheduling time zone. To change it, submit a ticket to contact technical support.
Existing tenants
If you already have workspaces in a supported region, submit a ticket to request the change. The process includes the following steps:
-
Your side: Assess the impact on historical data.
-
Platform side: Migrate historical data.
-
Platform side: Set the new time zone.
-
Your side: Restore historical data and verify the new time zone. Test each task type multiple times to confirm they run correctly.
After the change takes effect, verify the new time zone in Operation Center or on the Schedule tab of any node.
Verify the change
After the change takes effect, confirm the new time zone using either of the following methods.
Method 1: Check on the Schedule tab
-
Log on to the DataWorks console. In the top navigation bar, select the region. In the left navigation pane, choose Data Development and O&M > Data Development. Select the workspace and click Go to Data Development.
-
Open an existing node or create a new node.
-
On the node editing page, click Schedule > Scheduling Time and verify the new time zone is displayed.
This method does not apply to nodes in the new workflow UI.
Method 2: Check in Operation Center
Log on to the DataWorks console. Switch to the target region. In the left navigation pane, choose Data Development and O&M > Operation Center. Select the workspace and click Go to Operation Center. The current scheduling time zone is displayed in the notification bar at the top of the page.
Appendix: Handling time in Data Integration
The Data Integration time zone is independent of the DataWorks scheduling time zone and does not change when you switch the scheduling time zone.
Scheduling parameter replacement values are sent to Data Integration as strings. For example, the filter condition gmt_modify >= ${yyyymmdd} is sent to the data source as a string literal. The actual filtering result depends on the time zone processing mechanism of the data source.
The time zone for a Data Integration synchronization process is the local time zone of the region where the DataWorks workspace resides. This does not change with the DataWorks scheduling time zone. For some data sources, synchronization results may be affected by the synchronization process's time zone.