SERVER-10651 - MySQL's DATE_ADD DATE_SUB like functions for $project

[dribba]

It would be nice to count with something like DATE_ADD and DATE_SUB of MySQL where you can add or subtract intervals, not only milliseconds like the $add expression is doing now.
Right now all the add/subtract operations with date are handled like numbers, and some cases this is not enough, like adding months or years.
I propose to create new expressions to handle date addition/subtraction supporting units and also milliseconds. Like:
db.test.aggregate( { $project: { expiryDate: { $dateAdd: [ "$date", [5, "months"] ] } } });
db.test.aggregate( { $project: { lastYear: { $dateSub: [ "$date", [1, "years"] ] } } });

The code might need revision, we tried to complete all the tests(C++ and JS)

[kangas]

Hi David,

Thanks for contributing to MongoDB! I see that you created a server ticket, which is great. Have you also signed our contributor's agreement as noted in CONTRIBUTING.rst? See http://www.mongodb.com/contributor

I must warn you that proposals to change things this have a very high bar to clear. There is a good chance it won't be accepted, or that we'll ask you to rework it significantly. But I appreciate that you made an effort to write comprehensive tests.

I will try to get you the right person to review this as soon as I see you've signed the contributor agreement.

[dribba]

Hi Matt,
Yes, I signed it and confirmed.

Thanks for looking at this so soon :)

[amschwerin]

I am sorry for the very long delay in responding to this pull request. The user-experience goal is good. It would be nice to be able to generate date intervals by subtraction, and to add intervals to dates to produce new dates. I think I like the syntax, reasonably, too. However, to support this well, we really need a date arithmetic package that these aggregation operations would depend upon. The logic for what to do when you add 15 months to a date doesn't belong in the aggregation operators, but in a date arithmetic library. I'm not certain if there's a good, high performance existing library we could use, or if that would have to be written as prerequisite to this work.

Further thinking is also required on the storage representation of date and time types. The existing system cannot handle leap seconds, though nor can many SQL database date types. This means that timestamp arithmetic develops skew over time. A similar problem must exist for representing dates prior to the advent of the Gregorian calendar, etc., etc. A lot of this would only matter if you were trying to store information about astronomical events (when was Haley's coment directly above Witchita during the 19th century?), so we probably wouldn't need to go overboard, but the vagaries of solar time require at least a little discussion before we add these features.

[gabzim]

This was closed but never again revisited. It's important for reporting purposes using the aggregation framework. Say you want to aggregate by month and need to have a from & to date fields. you can't just add 30 days to the from date because months have varying numbers of days. @andy10gen