issue #528 - update Conformance.md and tweak datetime precision#529
Merged
prb112 merged 5 commits intolee-masterfrom Dec 21, 2019
Merged
issue #528 - update Conformance.md and tweak datetime precision#529prb112 merged 5 commits intolee-masterfrom
prb112 merged 5 commits intolee-masterfrom
Conversation
1. added a bunch more date and datetime tests to AbstractSearchDateTest (and reorganized some ones that were there) 2. found and fixed one problematic case: We were capturing the precision wrong for Datetime values which include 0 seconds. Our algorithm relied on TemporalAccessor.toString but this method actually excludes the seconds when they are 0. This was causing us to store values like `2019-12-31T20:00:00Z` as the range `[2019-12-31T20:00:00Z, 2019-12-31T20:00:59.999999Z)` instead of `[2019-12-31T20:00:00Z, 2019-12-31T20:00:00.999999Z)`. I addressed it by using the DateTime or Date PARSER_FORMATTER (depending on its type). 3. updated BasicDate.json to test with a more "interesting" dateTime...one that strattles the edge of a year, month, and day. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
prb112
reviewed
Dec 21, 2019
prb112
reviewed
Dec 21, 2019
prb112
reviewed
Dec 21, 2019
prb112
reviewed
Dec 21, 2019
The spec says "Where both search parameters and resource element date times do not have time zones, the servers local time zone should be assumed" and so I wanted to try seeing what that would look like. Its not very clear what is "correct" if only one of those two excludes time zones. It doesn't matter much on the parameter extraction side because all datetimes with times in them are required to have a timezone, but I think I like the idea of handling searches w/o timezone info via local time, because usually if someone puts a date or datetime without a timezone they are expecting local time and not UTC time. In the process, I also found a discrepency between our EQ and NE behavior. To rectify this, I removed the "exactly equals DATE_START" omptimization because I think its not always right...for example if the indexed value was actually a Period then we shold consider an exact point to be equal to that Period (even if the start matches). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com> Co-Authored-By: Paul Bastide <pbastide@us.ibm.com>
prb112
approved these changes
Dec 21, 2019
issue #528 - use server timezone to interpret dates
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
added a bunch more date and datetime tests to AbstractSearchDateTest
(and reorganized some ones that were there)
found and fixed one problematic case:
We were capturing the precision wrong for Datetime values which include
0 seconds. Our algorithm relied on TemporalAccessor.toString but this
method actually excludes the seconds when they are 0. This was causing
us to store values like
2019-12-31T20:00:00Zas the range[2019-12-31T20:00:00Z, 2019-12-31T20:00:59.999999Z)instead of[2019-12-31T20:00:00Z, 2019-12-31T20:00:00.999999Z). I addressed it byusing the DateTime or Date PARSER_FORMATTER (depending on its type).
dateTime...one that strattles the edge of a year, month, and day.
Signed-off-by: Lee Surprenant lmsurpre@us.ibm.com