N1QL: Date mutation functions should take into account length of months

When using date mutation functions, such as DATE_ADD_STR, it normalises the date when adding a month, for example:

SELECT DATE_ADD_STR('2020-01-31 00:00:00Z', 1, 'month') AS dateFuture

[

  {

    "dateFuture": "2020-03-02T00:00:00Z"

  }

]

This is due to the underlying Go library, as explained here:

AddDate normalizes its result in the same way that Date does, so, for example, adding one month to October 31 yields December 1, the normalized form for November 31.

This is not the expected outcome from an end user perspective, we would expect the outcome of the above example to be the 29th February.