Set timezone to UTC for all storedprocedure timestamps#527
Merged
Conversation
prb112
reviewed
Dec 20, 2019
lmsurpre
force-pushed
the
lee-master
branch
2 times, most recently
from
58a803c to
c83572e
Compare
also added `shutdownDatabase` placeholder in AbstractPersistenceTest Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
We found that some of the logic was wrong in the DateParmBehaviorUtil. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
commented
Dec 21, 2019
lmsurpre
commented
Dec 21, 2019
prb112
changed the title
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>
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>
issue #528 - use server timezone to interpret dates
issue #528 - update Conformance.md and tweak datetime precision
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.
also added
shutdownDatabaseplaceholder in AbstractPersistenceTestSigned-off-by: Lee Surprenant lmsurpre@us.ibm.com