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 Os X 10.10.5
Windows Server 2008 R2

Description of the problem including expected versus actual behavior :
Using a custom interval value denominated in weeks and a value greater than 1 (e.g., 2w) in a date_histogram aggregation request causes a ElasticsearchParseException saying "failed to parse setting."

Using custom intervals denominated in months also often fails. For example using 3M will convert to 13w and then cause the same parse exception.

Steps to reproduce :

Create a line visualization.

Select "Date Histogram" as the aggregation

Select "Custom" interval.

Enter "3w" as the interval value.

Apply.

Using 3M as the custom interval value also fails.

Provide logs (if relevant) :
Caused by: org.elasticsearch.ElasticsearchParseException: failed to parse setting [DateHistogramAggregationBuilder.interval] with value [13w] as a time value: unit is missing or unrecognized
at org.elasticsearch.common.unit.TimeValue.parseTimeValue(TimeValue.java:350) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.aggregations.bucket.histogram.DateHistogramAggregationBuilder.createRounding(DateHistogramAggregationBuilder.java:296) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.aggregations.bucket.histogram.DateHistogramAggregationBuilder.innerBuild(DateHistogramAggregationBuilder.java:277) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.aggregations.support.ValuesSourceAggregationBuilder.doBuild(ValuesSourceAggregationBuilder.java:300) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.aggregations.support.ValuesSourceAggregationBuilder.doBuild(ValuesSourceAggregationBuilder.java:49) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.aggregations.AbstractAggregationBuilder.build(AbstractAggregationBuilder.java:126) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.aggregations.AggregatorFactories$Builder.build(AggregatorFactories.java:211) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.SearchService.parseSource(SearchService.java:698) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.SearchService.createContext(SearchService.java:536) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:502) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:243) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.action.search.SearchTransportService.lambda$registerRequestHandler$6(SearchTransportService.java:276) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.transport.TransportRequestHandler.messageReceived(TransportRequestHandler.java:33) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:69) ~[elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.transport.TransportService$6.doRun(TransportService.java:548) [elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:504) [elasticsearch-5.0.0.jar:5.0.0]
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-5.0.0.jar:5.0.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_65]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_65]
[2016-11-09T11:35:07,464][DEBUG][o.e.a.s.TransportSearchAction] [he1jgGc] [batdash][3], node[he1jgGcRTkuopKIoPkhh8g], [P], s[STARTED], a[id=GPzlTqcdTkCEH_ZzpPUP5w]: Failed to execute [SearchRequest{searchType=QUERY_THEN_FETCH, indices=[batdash], indicesOptions=IndicesOptions[id=39, ignore_unavailable=true, allow_no_indices=true, expand_wildcards_open=true, expand_wildcards_closed=false, allow_alisases_to_multiple_indices=true, forbid_closed_indices=true], types=[], routing='null', preference='1478373887531', requestCache=null, scroll=null, source={
"size" : 0,
"query" : {
"bool" : {
"must" : [
"query_string" : {
"query" : "*",
"fields" : [ ],
"use_dis_max" : true,
"tie_breaker" : 0.0,
"default_operator" : "or",
"auto_generate_phrase_queries" : false,
"max_determined_states" : 10000,
"lowercase_expanded_terms" : true,
"enable_position_increment" : true,
"fuzziness" : "AUTO",
"fuzzy_prefix_length" : 0,
"fuzzy_max_expansions" : 50,
"phrase_slop" : 0,
"analyze_wildcard" : true,
"locale" : "und",
"escape" : false,
"boost" : 1.0
"range" : {
" @timestamp " : {
"from" : 1420145441771,
"to" : 1478029841772,
"include_lower" : true,
"include_upper" : true,
"format" : "epoch_millis",
"boost" : 1.0
"disable_coord" : false,
"adjust_pure_negative" : true,
"boost" : 1.0
"aggregations" : {
"2" : {
"date_histogram" : {
"field" : " @timestamp ",
"time_zone" : "America/New_York",
"interval" : "13w",
"offset" : 0,
"order" : {
"_key" : "asc"
"keyed" : false,
"min_doc_count" : 1
"aggregations" : {
"3" : {
"terms" : {
"field" : "NIIN",
"size" : 5,
"shard_size" : -1,
"min_doc_count" : 1,
"shard_min_doc_count" : 0,
"show_term_doc_count_error" : false,
"order" : [
"1" : "desc"
"_term" : "asc"
"aggregations" : {
"1" : {
"sum" : {
"field" : "DMD_QTY"
"ext" : { }
}}] lastShard [true]
org.elasticsearch.transport.RemoteTransportException: [he1jgGc][127.0.0.1:9300][indices:data/read/search[phase/query]]

It looks like support for "w" was dropped with #19102 which is marked as a breaking change for 5.0. It should be possible to express this as day intervals. I don't know about the Kibana side of things, they already seem to convert months to weeks. My guess is this should also happen for conversion of weeks to day intervals.

Week and month intervals are not correctly converted to a time unit supported by Elasticsearch elastic/kibana#9029