Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date field mapping "epoch_millis" errors on date aggregations with timezones other than UTC #31392

Closed
cbuescher opened this issue Jun 18, 2018 · 3 comments
Assignees
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v6.4.0 v7.0.0-beta1

Comments

@cbuescher
Copy link
Member

As demonstrated in elastic/kibana#19858, having a date field with "format": "epoch_millis" can cause
errors when running date histogram aggregations with a time zone other than UTC. I think this problem was introduced as a side effect of #30534. While throwing an error for parsing time values with "format": "epoch_millis" and timezones other than UTC looks like the intented behaviour (see #22621), it should be able to overwrite this by specifying format in the aggregation. This however doesn't seem to work currently on 6.x.

@cbuescher cbuescher added >bug :Search Foundations/Mapping Index mappings, including merging and defining field types v7.0.0 v6.4.0 labels Jun 18, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@cbuescher cbuescher self-assigned this Jun 18, 2018
@cbuescher
Copy link
Member Author

cbuescher commented Jun 18, 2018

Specifying format like this in the aggregation:

DELETE test_epochmilli_1

PUT test_epochmilli_1
{
  "settings" : {
        "number_of_shards" : 1,
        "number_of_replicas" : 0
  },
  "mappings": {
    "doc": {
      "properties": {
        "@timestamp": {
          "type": "date",
          "format": "epoch_millis"
        },
        "name": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT test_epochmilli_1/doc/1
{
  "@timestamp": 1477954800000,
  "name": "some_name"
}

GET test_epochmilli_1/_search
{
	"aggs": {
		"2": {
			"date_histogram": {
				"field": "@timestamp",
				"interval": "1M",
				"time_zone": "Europe/Berlin",
                                "format" : "yyyy-MM-dd",   <===== should overwrite "epoch_millis" from the mapping
				"min_doc_count": 1
			}
		}
	}
	
}

Throws

{
  "error": {
    "root_cause": [
      {
        "type": "parse_exception",
        "reason": "failed to parse date field [1477954800000] with format [epoch_millis]"
      }
    ],
    "type": "search_phase_execution_exception",
    "reason": "all shards failed",
    "phase": "query",
    "grouped": true,
    "failed_shards": [
      {
        "shard": 0,
        "index": "test_epochmilli_1",
        "node": "gOhPXLDVS4GRO2M1gHWXpA",
        "reason": {
          "type": "parse_exception",
          "reason": "failed to parse date field [1477954800000] with format [epoch_millis]",
          "caused_by": {
            "type": "illegal_argument_exception",
            "reason": "time_zone must be UTC for format [epoch_millis]"
          }
        }
      }
    ]
  },
  "status": 400
}

I would have expected it to use the specified format instead.

@cbuescher
Copy link
Member Author

I might have a fix, still working on tests though before opening a PR.

cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Jun 18, 2018
Currently, DateHistogramAggregationBuilder#rewriteTimeZone uses the aggregation
date math parser and time zone to check whether all values in a read have the
same timezone to speed up computation. However, the upper and lower bounds to
check are retrieved as longs in epoch_millis, so they don't need to get parsed
using a time zone or a parser other than "epoch_millis". This changes this
behaviour that was causing problems when the field type mapping was specifying
only "epoch_millis" as a format but a different timezone than UTC was used.

Closes elastic#31392
cbuescher pushed a commit that referenced this issue Jun 20, 2018
Currently, DateHistogramAggregationBuilder#rewriteTimeZone uses the aggregation
date math parser and time zone to check whether all values in a read have the
same timezone to speed up computation. However, the upper and lower bounds to
check are retrieved as longs in epoch_millis, so they don't need to get parsed
using a time zone or a parser other than "epoch_millis". This changes this
behaviour that was causing problems when the field type mapping was specifying
only "epoch_millis" as a format but a different timezone than UTC was used.

Closes #31392
cbuescher pushed a commit that referenced this issue Jun 20, 2018
Currently, DateHistogramAggregationBuilder#rewriteTimeZone uses the aggregation
date math parser and time zone to check whether all values in a read have the
same timezone to speed up computation. However, the upper and lower bounds to
check are retrieved as longs in epoch_millis, so they don't need to get parsed
using a time zone or a parser other than "epoch_millis". This changes this
behaviour that was causing problems when the field type mapping was specifying
only "epoch_millis" as a format but a different timezone than UTC was used.

Closes #31392
fixmebot bot referenced this issue in VectorXz/elasticsearch Apr 22, 2021
fixmebot bot referenced this issue in VectorXz/elasticsearch May 28, 2021
fixmebot bot referenced this issue in VectorXz/elasticsearch Aug 4, 2021
@javanna javanna added the Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v6.4.0 v7.0.0-beta1
Projects
None yet
Development

No branches or pull requests

4 participants