Operational Defect Database

BugZero found this defect 2397 days ago.

MongoDB | 413002

[SERVER-30523] dateFromParts should not reject "out-of-range" numbers for date/time properties

Last update date:

10/30/2023

Affected products:

MongoDB Server

Affected releases:

No affected releases provided.

Fixed releases:

3.7.2

Description:

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.

Additional Resources / Links

Share:

BugZero Risk Score

Coming soon

Status

Closed

Have you been affected by this bug?

cost-cta-background

Do you know how much operational outages are costing you?

Understand the cost to your business and how BugZero can help you reduce those costs.

Discussion

Login to read and write comments.

Have you ever...

had your data corrupted from a

VMware

bug?

Search:

...