Date range aggregation does not convert ranges

[lukasolson]

When you select a time range using the time picker (e.g. "Today"), the URL will update with a representation of this time range (e.g. { from: "now/d", to: "now/d" }). This is consistent with Elasticsearch's date math formats. However, what ends up being sent in the request to Elasticsearch isn't this same representation. It is converted to milliseconds since the epoch. You can see this in the request body:

{"range":{"date":{"gte":1483858800000,"lte":1484636400000,"format":"epoch_millis"}}}

From my understanding, the reasoning behind this is that the time on the Kibana/Elasticsearch server can be off from the time of the user using Kibana in the browser.

If you create a visualization, one of the aggregation types we support is "Date Range". If you select this aggregation, it allows you to specify different date ranges, and it accepts values in Elasticsearch date formats:

However, the range in this case does NOT get converted on the client into number of milliseconds since the epoch. You can see this in the request body:

{"date_range":{"field":"date","ranges":[{"from":"now/d","to":"now/d"}]}}

This is inconsistent. Either we should always be translating to milliseconds since the epoch, or we should always stick to the relative format.

[Bargs]

Related #9427

These custom dates are a pain, we should really define our own syntax and translate everything into millis as @lukasolson said.

[ppisljar]

We should think this thru well, find every place this applies, decide on solution and only then proceed.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.