Elasticsearch: Date rounding should include hours

[clintongormley]

In the following range query:

          "gte": "now/d",
          "lte": "now/d"

The gte value would be (eg) 2017-01-18 00:00:00 and the lte value would be 2017-01-18 23:59:59.

However, the rounding should not be based solely on the now/d but should include other adjustments, eg:

          "gte": "now/d+1h",
          "lte": "now/d+2h"

The gte value is as expected 2017-01-18 01:00:00 but the lte value is now 2017-01-19 01:59:59.

In other words the gap is 25 hours instead of 1 hour. The logic today is:

• round now down to the day
• then, because it is lte, add 24 hours - 1ms
• then add the +2h

Instead the logic should be:

• round now down to the day
• then add +2h
• then, because it is lte and the resolution is hours, add 60 min - 1ms

[martinscholz83]

Hey @clintongormley, what the label adoptme means? Maybe to start to contribute to elasticsearch?

[martinscholz83]

@dadoonet, thanks 👍

[martinscholz83]

Sounds good. To understand it correctly logic should be

"gte": "now/d"  2017-01-18 00:00:00
"lte": "now/d"   2017-01-18 23:59:59

"gte": "now/d+1h"  2017-01-18 01:00:00
"lte": "now/d+2h"   2017-01-18 01:59:59

"gte": "now/d+1m"  2017-01-18 00:01:00
"lte": "now/d+2m"   2017-01-18 00:01:59

[clintongormley]

Discussed in FixItFriday. We've decided that we want to keep the lte adjustment and to fix it to follow the following rules:

• lte adjustment only happens if rounding appears in the date math expression, eg now/d or 2017-01-01 14:53:12||/h
• Rounding is implemented as a floor operation on the date, using the specified unit
• Then, any other calculations are applied (eg +2h +10m) etc
• The smallest unit mentioned in the date math expression should be used for the lte adjustment,

For example:

• lte: now/d rounds down to midnight, then adds 24 hours minus 1ms
• lte: now/d+2h rounds down to midnight, adds two hours, then adds 1 hour minus 1 ms
• lte: now/h + 1d rounds down to the nearest hour, adds 24 hours, then adds 1 hour minus 1ms

This probably requires a significant rewrite of our date math parser.

[martinscholz83]

Hi @clintongormley

lte: now/d+2h rounds down to midnight, adds two hours, then adds 1 hour minus 1 ms

Do you mean

• lte: now/d+2h rounds down to midnight, adds two hours, then adds 24 hour minus 1 ms

[martinscholz83]

Hi @clintongormley, do you handle this issue internally or is there a chance to open a PR?

[clintongormley]

Do you mean
lte: now/d+2h rounds down to midnight, adds two hours, then adds 24 hour minus 1 ms

No, I do mean one hour. Because we've introduced the hour unit into the date maths, we should round at the hour precision, not the day precision.

do you handle this issue internally or is there a chance to open a PR?

Given the fact that we probably need a significant rewrite of the date math parser, I'd say that this is not low hanging fruit and would probably be better handled internally. thanks anyway

[jpountz]

cc @elastic/es-search-aggs