[SERVER-69548] Date arithmetic allows negative long long results that produce NaN when converted back to Date Created: 08/Sep/22 Updated: 05/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.0.28, 6.0.1, 4.4.16, 4.2.22, 5.0.11, 6.1.0-rc1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Kevin Cherkauer | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Operating System: | ALL |
| Participants: |
| Description |
|
Date arithmetic in aggregation pipeline allows negative long long results, but these produce NaN when converted back to Date type. SBE has this bug currently. Classic engine is being changed to match SBE via Reproduction in mongo shell: 1. Create a doc with a date field in it:
2. Add Decimal128(min(long long)) to this date:
This will produce an "NaN" result, which is not what we want:
What should happen instead is to receive an error, as is the case with Decimal128(max(long long) - 1) (upper-bound is exclusive, hence the -1 to avoid a different assertion):
Originally I thought the problem was an undetected underflow, but that was wrong as there is no underflow in this case. The problem is that the long long internal value used to store the date becomes negative, and this produces NaN when converted back to Date. It seems we need to either assert fail when Date arithmetic produces a negative value or support correctly converting negative values to Date values. |