victorsheng commented on issue #17885: URL: https://github.com/apache/dolphinscheduler/issues/17885#issuecomment-3770736402
The root cause of this issue is that the Master node utilizes the JVM's default timezone instead of the specific timezone defined in the Workflow's schedule configuration when calculating date ranges. This leads to time drift in cross-timezone environments. I have categorized the types of tasks that are affected: ## 1. Dependent Tasks (Most Critically Affected) This is the primary area identified in the issue. Impact Point: When configuring "Dependent Periods" such as today, last1Days, thisWeek, or last7Days, the Master calculates the required date range based on the system's local time (JVM TZ). Consequence: If the JVM is set to UTC+8 (Beijing) but the workflow is scheduled for UTC-6 (Central Standard Time), the Master may check for task status on the "wrong day" relative to the workflow's business logic, causing dependency check failures. ## 2. Tasks Using Time Placeholder Parameters Any task type that relies on dynamic variables like $[yyyy-MM-dd] or $[add_months(yyyyMMdd, -1)] is vulnerable. Impacted Tasks: Shell, SQL, Python, HTTP, and Data Integration tasks (DataX, Sqoop, SeaTunnel). Impact Point: The TimePlaceholderResolver performs offset calculations based on schedule_time. If it fails to apply the workflow's specific timezone during calculation, the resulting date string will be incorrect. Consequence: Scripts or queries will execute against the wrong data partitions (e.g., loading data for the 16th when it should be the 15th). ## 3. Data Quality Tasks Impact Point: These tasks often use "Source/Target Filters" to define the scope of data validation. Consequence: If these filters use timezone-sensitive dynamic parameters, the validation logic will scan the wrong time range, leading to false positives (incorrect alerts) or false negatives (missing actual data issues). ## 4. Conditions and Switch Tasks Impact Point: These tasks evaluate logic based on upstream status or variables. Consequence: If the logical expressions or "Global Variables" involved in the switch/condition rely on date-based calculations performed by the Master, the workflow may branch into the wrong path due to the timezone offset. ## 5. Sub-Process Tasks Impact Point: Parent workflows often pass calculated date parameters down to sub-processes. Consequence: If the parent workflow generates an incorrect date parameter due to the JVM timezone bias, the entire sub-process (and all its internal tasks) will inherit and operate on that incorrect business date. ## 6. Backfill / Complement Data Scenarios Impact Point: During backfill operations, the system generates a series of schedule_time instances. Consequence: If the internal logic for mapping these times to specific date strings depends on a faulty timezone conversion (especially for complex weekly or monthly offsets), the backfilled data will likely be inconsistent with the expected historical periods. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
