OPERATIONAL DEFECT DATABASE
...
...
BugZero found this defect 2721 days ago.
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.
xgen-internal-githook commented on Fri, 9 Feb 2018 15:16:13 +0000: Author: {'email': 'nicholas.zolnierz@mongodb.com', 'name': 'Nick Zolnierz', 'username': 'nzolnierzmdb'} Message: SERVER-30523: dateFromParts should not reject out-of-range numbers for date/time properties Branch: master https://github.com/mongodb/mongo/commit/695d94255348302be2d804e2187eb61e15cbb412 ian@10gen.com commented on Fri, 19 Jan 2018 19:25:14 +0000: justin.seyster nicholas.zolnierz just a heads up that we're adding this to the scope for Type Conversions. asya commented on Tue, 15 Aug 2017 06:55:32 +0000: Yes, it's part of type conversion scope. charlie.swanson commented on Mon, 14 Aug 2017 19:25:45 +0000: 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? asya commented on Fri, 4 Aug 2017 21:50:02 +0000: 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. asya commented on Fri, 4 Aug 2017 21:45:28 +0000: See note in description of SERVER-16347 about carrying too-large values.
