[hotfix-#1952][core|doris] Fix ARRAY and LARGEINT type conversion exc…#1956
[hotfix-#1952][core|doris] Fix ARRAY and LARGEINT type conversion exc…#1956yanghuaiGit merged 1 commit intoDTStack:masterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces configurable timezone handling in the DateUtil class to fix ARRAY and LARGEINT type conversion exceptions. The change allows users to optionally use the system's local timezone instead of the hardcoded GMT+8 timezone by setting the USE_LOCAL_TIMEZONE system property.
- Adds a system property flag to control timezone behavior
- Modifies the ThreadLocal date formatter initialization to conditionally use local or default timezone
- Maintains backward compatibility by defaulting to GMT+8 when the property is not set
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
|
|
||
| private static final String TIME_ZONE = "GMT+8"; | ||
|
|
||
| private static final boolean isUseLocalTimeZone = |
There was a problem hiding this comment.
The variable name isUseLocalTimeZone does not follow Java naming conventions. Boolean variables should not have the "is" prefix when they are constants. According to Java naming conventions and the codebase style (e.g., DEFAULT_IS_DAEMON in ExecutorUtils.java), this should be named USE_LOCAL_TIMEZONE or USE_LOCAL_TIME_ZONE.
| private static final boolean isUseLocalTimeZone = | |
| private static final boolean USE_LOCAL_TIMEZONE = |
| TimeZone timeZone; | ||
| if (isUseLocalTimeZone) { | ||
| timeZone = TimeZone.getDefault(); | ||
| } else { | ||
| timeZone = TimeZone.getTimeZone(TIME_ZONE); | ||
| } |
There was a problem hiding this comment.
The new timezone selection logic based on the USE_LOCAL_TIMEZONE system property lacks test coverage. The DateUtilTest.java file contains tests for the DateUtil class, but none verify the behavior when this system property is set. Consider adding tests to validate:
- The default behavior when
USE_LOCAL_TIMEZONEis not set (should use GMT+8) - The behavior when
USE_LOCAL_TIMEZONEis set to "true" (should use system default timezone) - The behavior when
USE_LOCAL_TIMEZONEis set to "false" (should use GMT+8)
…eptions
Purpose of this pull request
Which issue you fix
Fixes # (issue).
Checklist: