-
Notifications
You must be signed in to change notification settings - Fork 184
Fix instant handling #196
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 instant handling #196
Conversation
Java's `Instant` type is a fixed point in time (unix epoch which is always UTC) and therefore similar to `OffsetDateTime`. Currently Instant is mapped to a `TIMESTAMP` which is incorrect. This commit changes this to `TIMESTAMPTZ` which is Postgres' type for specific points in time and is the same way the official driver handles this.
The current DateCodec for legacy `java.util.Date` was using `java.time.Instant` which was itself incorrectly mapping to `TIMESTAMP`. With the previous fix to `InstantCodec` the codec of `Date` had to be changed so the more correct `LocalDateTimeCodec`.
@bzikarsky Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@bzikarsky Thank you for signing the Contributor License Agreement! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR. R2DBC type conversion isn't touching Date
and Instant
so we have a certain degree of freedom here.
Feel free to add Instant
and Date
to the readme and we're good to merge this pull request.
Awesome! I just added the 2 types to the README. |
Thanks a lot. That's merged and polished now. |
Instants were (IMO) incorrectly mapped to
TIMESTAMP
on the wire. The official postgres java docs say so as well.This PR includes two commits/changes:
a) Make
InstantCodec
useTIMESTAMPTZ
- this is straightforward, tests have been updated accordinglyb) Make
DateCodec
not useInstantCodec
anymore and useLocalDateTime
instead. This is a bit more involved as we have to make use of LocalDateTime handles dates without time properly and we need to do some date-object juggling in general.I guess this "breaks backwards compatibility" in a way, but as this can be considered a bug (we ran into this by accident as our test-suite just didn't want to turn green), it should still be fixed in my opinion.
If this passes the review, we could also add
Instant
to the supported types on theREADME
.I will also gladly sign the Contributing Agreement if this is required for this MR.