In data processing, you often need to dynamically generate partitions or filenames based on a task's runtime. To do this, you can use system-provided parameters to inject dynamic time values, such as the business date-based ${...} and the scheduled time-based $[...]. This topic compares the core differences between these parameter formats, focusing on precision, offset calculation, and use cases.
For more information about base time definitions and how to transform custom parameters, see Supported formats for scheduling parameters.
Comparison of custom parameter formats
Assume that the current time is November 01, 2025, and a task is scheduled to run daily at 00:00. The following table shows how different custom parameters are assigned.
Assume that the parameter is referenced in the code as pt=${datetime}.
Parameter format | Description | Scheduling parameter assignment | Parameter replacement result |
| Gets the business time. |
|
|
| Gets the scheduled time, accurate to the second. |
|
|
| Gets the business time. |
|
|
| Gets the scheduled time, accurate to the second. |
|
|
| Gets the current time, accurate to the day. |
|
|
| Gets the business month. The logic is as follows:
|
| For example, if the current time is
|
Core differences between ${…} and $[…] parameters
The following table compares the core differences between the ${…} and $[…] parameters.
Comparison |
|
|
Time baseline | Business date (T-1) | Scheduling time (T) |
Time precision | Day (year, month, day) | Second (year, month, day, hour, minute, second) |
Offset calculation capability | Supports offsets for years, months, weeks, and days. | Supports offsets for days, hours, and minutes. |
Core limitations | Does not support formatting or offset calculations for smaller units like hours, minutes, or seconds. | Does not support direct year or month offsets using syntax like |
Default equivalence |
|
|
For more information about how to use the
${…}and$[…]parameters, see Supported formats for scheduling parameters.For more information about how to configure and use custom parameters, see Configure and use scheduling parameters.
This topic uses an ODPS SQL node as an example. Assume that the scheduled time for the task is 10:30:00 on July 20, 2025. The following table shows the time value configurations for the ${…} and $[…] parameters.
Time value | ${…} parameter | $[…] parameter |
Obtain the year: 2025 |
|
|
Obtain the year: 25 |
|
|
Obtain the year: 2024 |
|
|
Obtain the month: 07 |
|
|
Obtain the day of the month: 20 |
|
|
Obtain the date: June 20, 2025 |
Important This method is not recommended because you must account for the number of days in the month. Use the |
|
Obtain the date: July 19, 2025 |
|
|
Obtain the date: July 20, 2024 |
Important This method is not recommended because you must account for leap years. Use the |
|
Obtain the time: 10:30:00 | Not supported |
|
Obtain the time: 2025-07-20 10:30:00 | Not supported |
|
Obtain the time: 2025-07-20 10:29:00 | Not supported |
|
Obtain the time: 2025-07-20 09:30:00 | Not supported |
|
Obtain the previous day's time, accurate to the second, with no space between the date and time: 2025071910:30:00 | Not supported |
|
Obtain the previous day's time, accurate to the second, with a space between the date and time: 20250719 10:30:00 | Not supported | Important Scheduling parameter assignment expressions do not support spaces. To include a space, you can define two scheduling parameters and then join them with a space in your code reference.
|