Range/date-range aggregation on a date field ignores the target field's format (timezone in particular) for defined ranges

[yrodiere]

Elasticsearch version (bin/elasticsearch --version): 7.13.3, 7.13.4, 7.14.0 (container image from DockerHub)

Plugins installed: []

JVM version (java -version): Whatever is included in the container image.

OS version (uname -a if on a Unix-like system):

Description of the problem including expected versus actual behavior:

In ES 7.13.3 and above (7.14.0 included), range and date_range aggregations interpret the bounds of ranges with some hardcoded format which is definitely not the format assigned to the target field in the mapping.

This can result in timezones being ignored and thus values being interpreted improperly.

This is different from the behavior in 7.13.2 and below.

This is also inconsistent with the behavior of the range query, which correctly uses the format of the target field.

Steps to reproduce:

curl -XPUT -H "Content-Type: application/json" 'localhost:9200/test/' -d'{"mappings": {"properties": {"mydate": {"type": "date", "format": "uuuu-MM-dd'\''T'\''HH:mm:ss.SSSSSSSSSZZZZZ" } } } }'
curl -XPUT -H "Content-Type: application/json" 'localhost:9200/test/_doc/1' -d '{"mydate": "2021-08-12T01:00:00.000000000+02:00" }'
curl -XPOST -H "Content-Type: application/json" 'localhost:9200/test/_search?size=0' -d '{"query":{"match_all":{}},"aggregations":{"myagg":{"range":{"field":"mydate","ranges":[{"from":"2021-08-12T00:00:00.000000000+02:00","to":"2021-08-12T02:00:00.000000000+02:00"}]}}}}'

Results on 7.13.3 and above (7.14.0 included); see how the timezone was simply stripped from the range bounds and completely ignored, resulting in a doc_count of 0:

{
  "took": 2,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "aggregations": {
    "myagg": {
      "buckets": [
        {
          "key": "2021-08-12T00:00:00.000000000Z-2021-08-12T02:00:00.000000000Z",
          "from": 1628726400000,
          "from_as_string": "2021-08-12T00:00:00.000000000Z",
          "to": 1628733600000,
          "to_as_string": "2021-08-12T02:00:00.000000000Z",
          "doc_count": 0
        }
      ]
    }
  }
}

Results on 7.13.2 and below:

{
  "took": 71,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "aggregations": {
    "myagg": {
      "buckets": [
        {
          "key": "2021-08-11T22:00:00.000000000Z-2021-08-12T00:00:00.000000000Z",
          "from": 1628719200000,
          "from_as_string": "2021-08-11T22:00:00.000000000Z",
          "to": 1628726400000,
          "to_as_string": "2021-08-12T00:00:00.000000000Z",
          "doc_count": 1
        }
      ]
    }
  }
}

On the other hand, the range query behaves correctly across all versions. if I run a range query, be it on 7.13.2, 7.13.3, 7.13.4 or 7.14.0, the bounds are correctly parsed according to the format of the target field:

 curl -XPOST -H "Content-Type: application/json" 'localhost:9200/test/_search?size=0' -d '{"query":{"range":{"mydate":{"gte":"2021-08-12T00:00:00.000000000+02:00","lt":"2021-08-12T02:00:00.000000000+02:00"}}}}'

{
  "took": 36,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  }
}

Provide logs (if relevant): N/A

[elasticmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[not-napoleon]

Thanks for reporting this. I'm not sure what would have changed between 7.13.2 and 7.13.3 that would cause this, but I'll take a look. There's definitely a lot of brittle code around time zones, so anything is possible. I'm about to be out of office for a few days, so it might be a little while before I get to this, but I will look into it.

[not-napoleon]

I built a test to reproduce this and ran it through git bisect; looks like I broke it in #73955. I've got some suspicions what might have happened. Will dig in and see if I can get it fixed. We can't just roll back #73955, because that fixes a different date formatting bug.