[release/3.1] Query: Assign datetime typemapping to DateTimeOffset.Date #19865
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
smitpatel
changed the title
smitpatel
changed the title
ajcvickers
approved these changes
Feb 11, 2020
|
@smitpatel Approved by Tactics and branches are open; let's try to get this merged today. |
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.
Resolves #19052
Description
When DateTimeOffset.Date is translated, we kept resulting type mapping as datetimeoffset so during comparison with other date, the parameter is created using wrong store type.
Customer Impact
Due to parameter type being wrong, it can have offset sometimes giving incorrect results of the query.
How found
Reported by multiple customers.
Test coverage
We did not have test coverage for specific scenario where DateTimeOffset.Date's type mapping mattered. This has been added.
Regression?
Possibly. We have verified the exact behavior in 2.x because a lot has changed in how we translate this, but it's likely this was broken in 2.x at least for some cases.
Risk
Low. Affects only translation of
DateTimeOffset.Datewhich was incorrect before this fix.Also, fix is on by default, but quirk switch is present to revert back to old behavior.