issue #2528 - change interpretation of lt and gt for date searches #2531
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
lmsurpre
force-pushed
the
issue-2528
branch
3 times, most recently
from
9d015f3
to
0958f20
Compare
|
Should the new builder util be updated with this change? |
tbieste
approved these changes
Jun 18, 2021
lmsurpre
force-pushed
the
issue-2528
branch
3 times, most recently
from
9d1d0bb
to
ce7f76d
Compare
For both date and number searches. We use the range interpretation of the search prefixes. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
I reworked the changes so that its now contained in the persistence layer and I updated both the old and new behavior classes |
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.
We use the range interpretation of the search prefixes for both date and
number/quantity searches. The spec says:
ltmeans "the range below the search value intersects (i.e. overlaps) with therange of the target value"
gtmeans "the range above the search value intersects (i.e. overlaps) with therange of the target value"
For numbers, the spec additionally says:
Previously, we interpreted date search in the same way and so a search like
gt2016would return any value above
2016-01-01 00:00:00in the server'stimezone. However, we were not consistent with this because, for some reason,
we decided that
lt2016should return any value below2017-01-01 00:00:00.However, even if we properly implemented this "arbitrarily high precision" clause for date search,
this interpretation leads to confusing and unintuitive results like
gt2016returning dates in 2016.Instead, we will now interpret the "search value" of 2016 to be the
range
[2016-01-01 00:00:00, 2017-01-01 00:00:00)and therefor a search forgt2016willonly find target values above 2017-01-01 00:00:00 (inclusive).
Signed-off-by: Lee Surprenant lmsurpre@us.ibm.com