Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: revert removal of toOffsetDateTime(String timestamp) fixes #Issue 2497 #2501

Merged
merged 4 commits into from
May 2, 2022

Conversation

davecramer
Copy link
Member

No description provided.

@vlsi
Copy link
Member

vlsi commented May 2, 2022

I guess we should restore 3d14ea4#diff-21e3023c84d9d5fb4f5f04678a094fce6ab5af36a5e73fdfaf495646f3b720d5L532 as well.

public OffsetDateTime toOffsetDateTime(Time t) {

* @param s The ISO formatted date string to parse.
* @return null if s is null or a OffsetDateTime of the parsed string s.
* @throws SQLException if there is a problem parsing s.
* @deprecated in favour of #toOffsetDateTime(String s, boolean adaptToUTC)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we suggest users to refrain from using TimestampUtils directly. We don't really want them to call toOffsetDateTime(String s, boolean adaptToUTC).

@vlsi
Copy link
Member

vlsi commented May 2, 2022

It looks like adaptToUTC is used in a single place only (in PgResultSet#getOffsetDateTime(int i)), so I wonder if we can move the logic to the call site.

That would allow reverting the signature back to its original state

Copy link
Member

@vlsi vlsi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LTGM

@davecramer
Copy link
Member Author

let's see if it passes the tests :)

@davecramer davecramer merged commit 4d711c2 into pgjdbc:master May 2, 2022
@davecramer
Copy link
Member Author

It looks like adaptToUTC is used in a single place only (in PgResultSet#getOffsetDateTime(int i)), so I wonder if we can move the logic to the call site.

That would allow reverting the signature back to its original state

Well the function needs

@uschindler
Copy link
Contributor

Looks fine to me.


}
if ( oid == Oid.TIMETZ ) {
return getTimestampUtils().toOffsetDateTime(castNonNull(getString(i)));
Copy link
Contributor

@uschindler uschindler May 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I first thought that we may need the atDate(LOCAL_DATE_EPOCH) here. But its not needed because a ParsedDatestamp instance defaults to epoch, too: https://github.com/davecramer/pgjdbc/blob/28e3434c5f751f54bd49e0a2c2a88dff45524222/pgjdbc/src/main/java/org/postgresql/jdbc/TimestampUtils.java#L165

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you suggesting a change here or just commenting on the existing code ?

Copy link
Contributor

@uschindler uschindler May 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, this was just a note to the reader (but could possibly added asa comment). The TIMETZ value is just a time in string format. But as above link tells you, the toOffsetDateTime(String) adds the EPOCH already, because the year/month/day values in ParsedTimestamp default to 1970, 1, 1, so when we convert the ParsedDatestamp instance to OffsetDateTime it get the default values. I was just unsure about this when reviewing the patch.

Sorry for the comment, it was just informational.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants