DataWorks:Supported formats for scheduling parameters

Basic usage principles

You can define the assignment logic for scheduling parameters by setting a parameter name and a parameter value in the Scheduling > Scheduling Parameters section. After you define a parameter, you can reference it in your code using the ${parameter_name} format. For more information about how to configure parameters, see Configure and use scheduling parameters.

• You can directly use the built-in system parameters $bizdate and $cyctime for the business date and scheduling time, respectively. They are equivalent to the following:

  • $bizdate = ${yyyymmdd}

  • $cyctime = $[yyyymmddhh24miss]

    The figures compare the parameter definitions for $bizdate and ${yyyymmdd}, and for $cyctime and $[yyyymmddhh24miss]. The figures also show the preview results when the business date is October 16, 2025.

• If the return values of the baseline time parameters do not meet your requirements, you can create custom time parameters using ${...} and $[...]. Custom time parameters are transformations based on the two time baselines.

Core differences between ${...} and $[...]

The ${...} and $[...] formats have fundamental differences in their time baselines and calculation capabilities. Using the wrong format will cause data errors.

Time formatting

You can use curly braces ${...} or square brackets $[...] combined with a custom combination of yyyy, yy, mm, and dd to generate time parameters. This lets you retrieve dates N years, months, or days before or after the business date.

Offset calculations

Offset calculation is a core feature of dynamic parameters that lets you add or subtract time from the business date or scheduling time. For example, you can retrieve dates N years, months, or days before or after the baseline. You can also retrieve times N hours or minutes before or after the baseline, but this is supported only for scheduling time. The ${...} and $[...] formats support different ranges because they have different time baseline precisions.

1. Offset calculation in ${...} mode

   • Core capability: Supports integer offsets for years, months, weeks, and days.

     Important

     Hour or minute offsets are not supported. For example, syntax such as ${yyyy-mm-dd-1/24} is invalid.

   • Syntax: ${<time_format><±N>}. In this format, N corresponds to the smallest unit of the time format. For example, if the format is yyyymm, N represents an offset in months (mm). If the format is yyyymmdd, N represents an offset in days (dd).

     Date offset period	Offset unit	Method	Example
     N years before/after	Year	${yyyy±N} or ${yy±N}	Previous year: ${yyyy-1}
     N months before/after	Month	${yyyymm±N}	Previous month: ${yyyymm-1}
     N weeks before/after	Week	${yyyymmdd±7*N}	Previous week: ${yyyymmdd-7*1}
     N days before/after	Day	${yyyymmdd±N}	Day before yesterday: ${yyyymmdd-1}

2. Offset calculation in $[...] mode

   • Core capability: Supports fractional offsets for days, hours, and minutes.

     Important

     The $[...] format does not support year or month offsets using formats such as $[yyyy-N] or $[mm-N]. To perform offset calculations on years or months, use the add_months function.

   • Syntax: $[<time_format><±N>]. To specify an hour offset, use N/24. To specify a minute offset, use N/24/60. In these expressions, N is the number of hours or minutes for the offset.

     Scenario	Offset unit	Method	Example
     N years before/after	Year	$[add_months(yyyymmdd,12*N)] (N years after) $[add_months(yyyymmdd,-12*N)] (N years before)	Previous year: $[add_months(yyyymmdd,-12)]
     N months before/after	Month	$[add_months(yyyymmdd,N)] (N months after) $[add_months(yyyymmdd,-N)] (N months before)	Previous month: $[add_months(yyyymmdd,-1)]
     N weeks before/after	Week	$[yyyymmdd±7*N]	Previous week: $[yyyymmdd±7*1]
     N days before/after	Day	$[yyyymmdd±N]	Yesterday: $[yyyymmdd-1]
     N hours before/after	Hour	Available formats: $[hh24miss±N/24], $[hh24±N/24] $[Custom time format±N/24].	Previous hour in different formats: Month: $[mm-1/24]. Year: $[yyyy-1/24]. Year and month: $[yyyymm-1/24]. Year, month, and day: $[yyyymmdd-1/24]. Previous day and previous hour: $[yyyymmdd-1-1/24]
     N minutes before/after	Minute	Available formats: $[hh24miss±N/24/60] $[yyyymmddhh24miss±N/24/60] $[mi±N/24/60] $[custom time format±N/24/60]	15 minutes before the scheduling time in different formats: $[yyyy-15/24/60] $[yyyymm-15/24/60] $[yyyymmdd-15/24/60] $[hh24-15/24/60] $[mi-15/24/60]
     Complex combined offset	Day + Hour	$[yyyymmdd±N±M/24], where N is the day offset and M is the hour offset.	Example: Get the previous day and previous hour → $[yyyymmdd-1-1/24]

     Note

     • When you perform offset calculations for hours and minutes, a cross-day issue may occur. For more information about how to handle cross-day parameter replacements, see How do I handle cross-day parameter replacement when I subtract one hour from a scheduling parameter?.

     • When you perform a month offset calculation on a month-end date, if the target month does not have that date, the result is automatically calibrated to the last day of the target month. For example, if the current date is 2025-03-31 and you subtract one month, the result is 2025-02-28 because February does not have a 31st day.

Secondary transformations using engine functions

If the built-in formatting and offset features cannot generate the value you need (for example, retrieving the last day of the previous month), you can use the built-in functions of the target node's compute engine or an assignment node to perform a secondary transformation on the time parameter when you call it.

For more information, see Typical scenarios for secondary processing of scheduling parameter return values.

String concatenation

You can use this method to construct specific date strings that are not supported by the built-in syntax but follow a regular pattern. This method combines the date part generated by a scheduling parameter with a fixed constant string.

Scenario 1: Normal scheduling

In a normal automated scheduling scenario, the parameter replacement logic corresponds directly to the two time baselines: the business date and the scheduling time.

• ${...} (business date): Its value is determined by the instance's own business date.

• $[...] (scheduling time): Its value is determined by the instance's own scheduling time.

Example: Assume a daily scheduling task A is scheduled to run at 00:00 every day and has two parameters configured:

• yesterday=${yyyymmdd}

• today=$[yyyymmddhh24miss]

The following table shows the replacement logic for one of its instances.

Scenario 2: Data backfill

When you manually run a data backfill task, the parameter replacement logic changes based on the manually selected business date, especially for the scheduling time.

• ${...} (business date): Its baseline is the manually selected business date.

• $[...] (scheduling time): Its baseline is the manually selected business date + 1 day.

Example: Assume you manually run a data backfill for the same task A and select the business date 2025-03-15.