PHOENIX-7856 User defined time zone doesn't work for timestamp filed …#2486
Open
mokai87 wants to merge 1 commit into
Open
PHOENIX-7856 User defined time zone doesn't work for timestamp filed …#2486mokai87 wants to merge 1 commit into
mokai87 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…in CSVBulkload
What changes were proposed in this pull request?
a) Refactor DateUtil.parseTimestamp to accept an optional DateTimeParser parameter,
enabling custom timezone-aware timestamp parsing. The nanoseconds extraction logic
was isolated into a separate private method to avoid duplication across code paths.
b) Update CsvUpsertExecutor and JsonUpsertExecutor to pass the user-defined
DateTimeParser into DateUtil.parseTimestamp, so CSV/JSON upsert operations respect
configured timezone settings for timestamp columns.
c) Add unit tests for custom timezone (GMT+8), and nanoseconds preservation.
Why are the changes needed?
The original parseTimestamp always forced UTC timezone, ignoring any user-defined timezone parser configuration. This caused incorrect timestamp values when importing data via CSV/JSON from non-UTC timezones. The refactored method now respects the DateTimeParser's timezone when provided, while maintaining backward compatibility by falling back to UTC when the parser is null.
Does this PR introduce any user-facing change?
After this change, CSV and JSON upsert operations will correctly interpret timestamp values according to the configured timezone parser instead of always treating them as UTC. Users who previously relied on the UTC-only behavior may need to adjust their input data or explicitly set the timezone configuration.
How was this patch tested?
Was this patch authored or co-authored using generative AI tooling?
Generated-by: OpenCode 1.15.5 + GLM-4.7