[Fix-18015] [DST ISSUE] Handle DST issue when calculating yyyyMMdd±N time placeholders#18026
[Fix-18015] [DST ISSUE] Handle DST issue when calculating yyyyMMdd±N time placeholders#18026iampratap7997-dot wants to merge 7 commits intoapache:devfrom
Conversation
| Date targetDate = addMinutes(date, calcMinutes(addMinuteExpr)); | ||
| if (index + 1 < expression.length() && Character.isDigit(expression.charAt(index + 1))) { | ||
| String addDayExpr = expression.substring(index + 1); | ||
| int days = Integer.parseInt(addDayExpr); |
Check notice
Code scanning / CodeQL
Missing catch of NumberFormatException
| Date targetDate = addMinutes(date, 0 - calcMinutes(addMinuteExpr)); | ||
| if (index + 1 < expression.length() && Character.isDigit(expression.charAt(index + 1))) { | ||
| String addDayExpr = expression.substring(index + 1); | ||
| int days = Integer.parseInt(addDayExpr); |
Check notice
Code scanning / CodeQL
Missing catch of NumberFormatException
|
HI maintainers, Thanks, |
|
Hi , I've fixed the DST issue occurring in the recent test case and also addressed the Copilot issues. Thanks, |
There was a problem hiding this comment.
Pull request overview
This PR aims to fix DST-related date drift when evaluating day-based time placeholders like $[yyyyMMdd±N] by switching from minute-based offsets to calendar-day arithmetic.
Changes:
- Replaces minute-based “day” adjustments in
calcMinutes(String, Date)withLocalDate.plusDays/minusDaysusing the system timezone. - Simplifies
this_day(...)calculation to return the provideddatedirectly. - Updates imports to support the new java.time-based implementation.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
...i/src/main/java/org/apache/dolphinscheduler/plugin/task/api/parser/TimePlaceholderUtils.java
Show resolved
Hide resolved
| @@ -18,8 +18,6 @@ | |||
| package org.apache.dolphinscheduler.plugin.task.api.parser; | |||
|
|
|||
| import static org.apache.commons.lang3.time.DateUtils.addWeeks; | |||
| public static Map.Entry<Date, String> calcMinutes(String expression, Date date) { | ||
| if (expression.contains("+")) { | ||
| int index = expression.lastIndexOf('+'); | ||
|
|
||
| if (Character.isDigit(expression.charAt(index + 1))) { | ||
| String addMinuteExpr = expression.substring(index + 1); | ||
| Date targetDate = addMinutes(date, calcMinutes(addMinuteExpr)); | ||
| if (index + 1 < expression.length() && Character.isDigit(expression.charAt(index + 1))) { | ||
| String addDayExpr = expression.substring(index + 1); | ||
| int days; | ||
| try { | ||
| days = Integer.parseInt(addDayExpr); | ||
| } catch (NumberFormatException e) { | ||
| return null; | ||
| } |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Was this PR generated or assisted by AI?
NO (Only the manual test case for America(Los_Angeles) timezone was created by AI to verify the fix.)
Purpose of the pull request
Fixes #18015 DST issue when calculating $[yyyyMMdd±N] time placeholders.
Day-based calculations were previously implemented in minutes, which caused incorrect dates during Daylight Saving Time transitions.
Brief change log
1- Replaced minute-based day calculations with addDays for expressions like yyyyMMdd+N & yyyyMMdd-N.
2- Ensures correct date calculation in timezones with DST (e.g., America/Los_Angeles).
Verify this pull request
Pull Request Notice
Pull Request Notice
If your pull request contains incompatible change, you should also add it to
docs/docs/en/guide/upgrade/incompatible.md