Support for Instant and OffsetDateTime #656
Open
Conversation
This file contains 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 variable ZONE_DATE_TIME (now OFFSET_DATE_TIME) is really a pattern for offset-based timestamps, not zoned timestamps. The variable should be named accordingly.
lbruun
changed the title
|
Thanks, I'll review it when I have some time. |
|
@lbruun This PR is just for the 6.2 branch, therefore I cannot integrate it unless the changes are provided for all modules. |
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.
Support for
Range<Instant>andRange<OffsetDateTime>Support for additional Java range types is added as per the text in bold in table below.
Supported PostgreSQL types:
int4rangeRange<Integer>int8rangeRange<Long>numrangeRange<BigDecimal>tsrangeRange<LocalDateTime>tstzrangeRange<ZonedDateTime>,Range<OffsetDateTime>orRange<Instant>daterangeRange<LocalDate>The change is fully backwards compatible.
Fixes Issue #288 and Issue #96.
Support for Instant-based comparison
Comparison functionality which can check for "functionally equivalent" has been added. With the existing "strict comparison" the following two ranges:
is seen as two completely different ranges and
contains()produces unexpected results in that the2007-12-03T09:30.00ZInstant is not contained in the x2 range. (see Issue #655)This PR adds new methods which performs Instant-based comparison where applicable, meaning for types
OffsetDateTimeandZonedDateTime. Fixes Issue #655.I don't see why not any application would want to always do
contains(x, true)going forward, but I didn't dare break backward compatibility. Hence the new feature is purely opt-in based. There is probably a slight performance degradation by performing Instant-based comparison instead of strict comparison, but I doubt it is truly measurable.