ESQL: Enhanced DATE_TRUNC with arbitrary intervals

[kanoshiou]

Originally, DATE_TRUNC only supported 1-month and 3-month intervals for months, and 1-year interval for years, while arbitrary intervals were supported for weeks and days. This PR adds support for DATE_TRUNC with arbitrary month and year intervals.

Closes #120094

[kanoshiou]

Although it is possible to specify an arbitrary interval of months or years in this PR, wouldn't it be clearer to allow users to specify a reference time from which to start calculating the interval? I'm not sure.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[alex-spies]

@bpintea , do you maybe want to have a look at this one? It's related to BUCKET, your favorite :)

[bpintea]

I think it looks good. Left some minor comments.

• Let's rename the PR and its description to reflect the impact on DATE_TRUNC. BUCKET is a side effect (despite the issue being about it).

• Could we please add more CSV test with the new intervals, which should make it easy to check, in the lines of: ROW x = ["1970-04-10", "1970-04-11", "1970-04-12"]::DATETIME | MV_EXPAND x | EVAL y = DATE_TRUNC(2 days, x) and/or similar with ...| STATS COUNT(*) BY BUCKET(...) for the newly available intervals.

CC @not-napoleon this updates some utils used by the histogram aggs, should you want to have a look.

[bpintea]

@elasticsearchmachine test this please

[kanoshiou]

There are some failing tests in DateTruncTests, and I plan to address them later.

[kanoshiou]

I believe this PR is now ready for review. It would be great if you could take a moment to look through it @bpintea !

[bpintea]

buildkite test this

[kanoshiou]

Sorry I forgot to run the CsvTests for another round of checks...

[bpintea]

buildkite test this

[bpintea]

Thanks!
It LGTM, but will ask for a review from other aggs-contributors, since the changes affect those too.

[not-napoleon]

Hi, "other aggs-contributor" here. I am a little concerned about performance here. This adds a lot more math, especially in the month case, and the rounding logic often runs in very hot loops so we need to be careful about performance there. At a minimum, I'd like us to delegate the "multiplier" == 1 case to the original methods.

@bpintea we should make sure to keep an eye on the benchmarks after merging this too.

Also, it would be nice if you added some more comments about how the date math works. This stuff is always tricky, and any help to our future selves when we need to modify it would be nice. Thank you!

[kanoshiou]

Thank you for reviewing, @bpintea @not-napoleon!

I've implemented some minor performance improvements and added detailed comments to clarify roundIntervalMonthOfYear and roundYearInterval.

[bpintea]

buildkite test this

[bpintea]

buildkite test this

[not-napoleon]

This addresses my concerns from a classic aggregations perspective. And thank you for adding more explicit comments about the date math, future me will be very happy the next time I need to touch that code.

[bpintea]

Thanks @kanoshiou for this contribution and your patience.

[luigidellaquila]

Manual backport: #129643