RDB archive: Fix Oracle time zone problem. #3675
Merged
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
The sample.smpl_time is handled differently for MySQL, Postgres, Oracle. In MySQL, it's stored as UTC. The `Timestamp` passed to `PreparedStatement.setTimestamp(Timestamp)` is converted to UTC and stored as UTC. On retrieval, `ResultSet.getTimestamp` converts back to the local time zone with appropriate GMT offset. In Postgres, we need to use a `TIMESTAMPTZ` datatype that stores the stamp with timezone info. Both MySQL and Postgres handle the fall transition from daylight savings time back to standard time just fine. In Oracle, even if we use `TIMESTAMP WITH TIMEZONE` for smpl_time, Oracle JDBC will second-guess the Timestamp passed to `setTimestamp(Timestamp)` and change the time offset. During the DST change in the fall, time stamps will be written with the wrong GMT offset. The workaround is to use `setObject(OffsetDateTime)` because OffsetDateTime is passed through and written as received.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The sample.smpl_time is handled differently for MySQL, Postgres, Oracle.
In MySQL, it's stored as UTC. The
Timestamppassed toPreparedStatement.setTimestamp(Timestamp)is converted to UTC and stored as UTC. On retrieval,ResultSet.getTimestampconverts back to the local time zone with appropriate GMT offset.In Postgres, we need to use a
TIMESTAMPTZdatatype that stores the stamp with timezone info.Both MySQL and Postgres handle the fall transition from daylight savings time back to standard time just fine.
In Oracle, even if we use
TIMESTAMP WITH TIMEZONEfor smpl_time, Oracle JDBC will second-guess the Timestamp passed tosetTimestamp(Timestamp)and change the time offset. During the DST change in the fall, time stamps will be written with the wrong GMT offset.The workaround is to use
setObject(OffsetDateTime)because OffsetDateTime is passed through and written as received.Checklist
Data during the last EDT to EST change might look like this:
2025-11-02T00:30-04:00
2025-11-02T01:30-04:00
2025-11-02T01:30-05:00
2025-11-02T02:30-05:00
Note that the local time 01:30 is logged with the correct time zone info during the transition.
Before this change, with Oracle you would get
2025-11-02T00:30-04:00
2025-11-02T01:30-04:00
2025-11-02T01:30-04:00
2025-11-02T02:30-05:00
or
2025-11-02T00:30-04:00
2025-11-02T01:30-05:00
2025-11-02T01:30-05:00
2025-11-02T02:30-05:00
where both instances of 01:30 are erroneously in the same zone offset.