date_histogram extendedBounds(DateTime,DateTime) failed when using format option

[dadoonet]

This code was working in elasticsearch 1.1.1:

SearchResponse response = esClient.prepareSearch("person")
  .addAggregation(
    AggregationBuilders.dateHistogram("by_year")
      .field("dateOfBirth")
      .minDocCount(0)
      .interval(DateHistogram.Interval.YEAR)
      .extendedBounds(DateTime.parse("1940"), DateTime.parse("2009"))
      .format("YYYY")
  )
  .execute().actionGet();

From elasticsearch 1.2.0, it fails with:

[2014-06-04 12:54:38,337][DEBUG][action.search.type       ] [Karla Sofen] [person][0], node[wTCLjroMSk-3LPUx3dIdlA], [P], s[STARTED]: Failed to execute [org.elasticsearch.action.search.SearchRequest@300f4bad] lastShard [true]
org.elasticsearch.ElasticsearchParseException: failed to parse date field [1940-01-01T00:00:00.000Z], tried both date format [YYYY], and timestamp number
    at org.elasticsearch.common.joda.DateMathParser.parseStringValue(DateMathParser.java:226)
    at org.elasticsearch.common.joda.DateMathParser.parse(DateMathParser.java:68)
    at org.elasticsearch.common.joda.DateMathParser.parse(DateMathParser.java:42)
    at org.elasticsearch.search.aggregations.support.format.ValueParser$DateMath.parseLong(ValueParser.java:96)
    at org.elasticsearch.search.aggregations.bucket.histogram.ExtendedBounds.processAndValidate(ExtendedBounds.java:52)
    at org.elasticsearch.search.aggregations.bucket.histogram.HistogramAggregator$Factory.create(HistogramAggregator.java:178)
    at org.elasticsearch.search.aggregations.bucket.histogram.HistogramAggregator$Factory.create(HistogramAggregator.java:137)
    at org.elasticsearch.search.aggregations.support.ValuesSourceAggregatorFactory.create(ValuesSourceAggregatorFactory.java:54)
    at org.elasticsearch.search.aggregations.AggregatorFactories.createAndRegisterContextAware(AggregatorFactories.java:52)
    at org.elasticsearch.search.aggregations.AggregatorFactories.createTopLevelAggregators(AggregatorFactories.java:145)
    at org.elasticsearch.search.aggregations.AggregationPhase.preProcess(AggregationPhase.java:79)
    at org.elasticsearch.search.query.QueryPhase.execute(QueryPhase.java:99)
    at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:257)
    at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:206)
    at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:203)
    at org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:517)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.IllegalArgumentException: Invalid format: "1940-01-01T00:00:00.000Z" is malformed at "-01-01T00:00:00.000Z"
    at org.elasticsearch.common.joda.time.format.DateTimeFormatter.parseMillis(DateTimeFormatter.java:754)
    at org.elasticsearch.common.joda.DateMathParser.parseStringValue(DateMathParser.java:220)
    ... 18 more

Of course, it works nicely when using extendedBounds(String, String) instead of extendedBounds(DateTime, DateTime):

SearchResponse response = esClient.prepareSearch("person")
  .addAggregation(
    AggregationBuilders.dateHistogram("by_year")
      .field("dateOfBirth")
      .minDocCount(0)
      .interval(DateHistogram.Interval.YEAR)
      .extendedBounds("1940", "2009")
      .format("YYYY")
  )
  .execute().actionGet();

As it was working in 1.1.1, should we consider this as a regression or is it by design?

[bakura10]

I'm having this issue to. Using a timestamp for extended bounds also make the trick.

[clintongormley]

@colings86 could take a look at this please

[dadoonet]

Reading the existing code in master (5.0), extendedBounds method only supports now a ExtendedBounds object.

ExtendedBounds only supports the following CTORs:

public ExtendedBounds(Long min, Long max);
public ExtendedBounds(String minAsStr, String maxAsStr);

So we can't hit this issue anymore in 5.0.

Closing but feel free to reopen if you think closing it was a mistake.