issue #528 - use server timezone to interpret dates#530
Merged
prb112 merged 2 commits intolee-master-patch1from Dec 21, 2019
Merged
issue #528 - use server timezone to interpret dates#530prb112 merged 2 commits intolee-master-patch1from
prb112 merged 2 commits intolee-master-patch1from
Conversation
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>
prb112
reviewed
Dec 21, 2019
prb112
approved these changes
Dec 21, 2019
Contributor
prb112
left a comment
prb112
left a comment
There was a problem hiding this comment.
please make the tense changes in the other PR
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.
This PR builds on #529 and can be taken in whole or in part.
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 see 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