Info
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.
Top User Comments
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.
