[SERVER-30523] dateFromParts should not reject "out-of-range" numbers for date/time properties Created: 04/Aug/17 Updated: 30/Oct/23 Resolved: 09/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Asya Kamsky | Assignee: | Nicholas Zolnierz |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Sprint: | Query 2017-08-21, Query 2017-09-11, Sharding 2018-02-12 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
Currently $dateFromParts will handle appropriately a day that's bigger than largest day in the specified month (i.e. year:2017, month:2, day:30 correctly becomes "2017-03-02" since there are only 28 days in February) but if day is >31 it gives an error. Same for month>12. ”‘day’ must evaluate to an integer in the range 1 to 31, found 32" Instead it should just construct appropriate date (so 2017, 2, 32 is "2017-03-03" and 2017 month 13 is January of 2018. This allows simple construction of dates that are X days after given date or Y months after given date, etc. |
| Comments |
| Comment by Githook User [ 09/Feb/18 ] |
|
Author: {'email': 'nicholas.zolnierz@mongodb.com', 'name': 'Nick Zolnierz', 'username': 'nzolnierzmdb'}Message: |
| Comment by Ian Whalen (Inactive) [ 19/Jan/18 ] |
|
justin.seyster nicholas.zolnierz just a heads up that we're adding this to the scope for Type Conversions. |
| Comment by Asya Kamsky [ 15/Aug/17 ] |
|
Yes, it's part of type conversion scope. |
| Comment by Charlie Swanson [ 14/Aug/17 ] |
|
Have we considered making a more obvious way to convert milliseconds since epoch to a date? That feels like a pretty useful thing to have, and now might be our chance? |
| Comment by Asya Kamsky [ 04/Aug/17 ] |
|
Note that milliseconds should accept a long since a legitimate use case is to convert milliseconds since epoch to ISODate (or seconds since epoch). millis = 1501883159318 date:{$dateFromParts:{year:1970, milliseconds: 1501883159318}} should be a legit expression. |
| Comment by Asya Kamsky [ 04/Aug/17 ] |
|
See note in description of |