[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:
Documented
is documented by DOCS-11444 Docs for SERVER-30523: dateFromParts ... Closed
Related
related to SERVER-40573 timelib can read past end of buffer, ... Closed
related to SERVER-16347 Support for date aggregation operator... Closed
is related to SERVER-34949 Improved safety for time_support.h API Closed
is related to SERVER-40383 dateFromParts does not overflow corre... Closed
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: SERVER-30523: dateFromParts should not reject out-of-range numbers for date/time properties
Branch: master
https://github.com/mongodb/mongo/commit/695d94255348302be2d804e2187eb61e15cbb412

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 SERVER-16347 about carrying too-large values.

Generated at Thu Feb 08 04:24:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.