date_histogram interval uses xM as xm

[pickypg]

The date_histogram interval is parsing "3M" as though it were minutes (e.g., "3m"). This leads to aggregations that should be invalid being accepted that create a massive number of buckets given the wrong data set.

An example aggregation that has a painfully large response (5 months created a ~700K lines of pretty printed JSON with only 4 documents in the index):

{
  "aggregations": {
    "byMonth": {
      "date_histogram": {
        "field": "begintime",
        "interval": "3M"
      },
      "aggregations": {
        "attrs": {
          "terms": {
            "field": "primaryattribution"
          },
          "aggregations": {
            "avg_by_attrs": {
              "avg": {
                "field": "pageviews"
              }
            }
          }
        }
      }
    }
  }
}

As an important note, "1M" appropriately gets interpreted as "month".

[xuzha]

We only support arbitrary values for time units up to weeks in the TimeValue class. date_histogram used it to parse the time interval. And in 2.0, when parsing timevalue, we made it case insensitive ( #11437), so now it accepts M as minute.

We may keep it as case insensitive, change the time unit Moth from M to mon or something clearer to user. @clintongormley WDYT

[colings86]

I think we need to keep month as M as this is what we expect in our date formats and data math so it is consistent. While I think most validation in the codebase should be case-insensitive I think in this case it should not be. All the other options (y,q,w,h,s) should be case in-sensitive too as in the date format syntax their uppercase and lowercase forms still relate to the same interval, but M and m have different meaning in the date format and the date math so we need to honour that here IMHO

[jpountz]

@colings86 was it fixed by #19649?

[colings86]

@jpountz yes, sorry, will close this now