Add time zone setting for relative date math in range filter/query

[dadoonet]

Filters and Queries now supports time_zone parameter which defines which time zone should be applied to the query or filter to convert it to UTC time based value.

When applied on date fields the range filter and queries accept also a time_zone parameter.

The time_zone parameter will be applied to your input lower and upper bounds and will move them to UTC time based date:

{
    "constant_score": {
        "filter": {
            "range" : {
                "born" : {
                    "gte": "2012-01-01",
                    "lte": "now",
                    "time_zone": "+1:00"
                }
            }
        }
    }
}

{
    "range" : {
        "born" : {
            "gte": "2012-01-01",
            "lte": "now",
            "time_zone": "+1:00"
        }
    }
}

In the above examples, gte will be actually moved to 2011-12-31T23:00:00 UTC date.

NOTE: if you give a date with a timezone explicitly defined and use the time_zone parameter, time_zone will be
ignored. For example, setting from to 2012-01-01T00:00:00+01:00 with "time_zone":"+10:00" will still use +01:00 time zone.

Closes #3729.

[jpountz]

Not sure it is needed? I would expect DateTimeZone.UTC.getOffset to already have this optimization and constantly return 0?

[dadoonet]

Agreed. Removed.

[jpountz]

Instead of always moving the time after the date is parser, maybe we should rather configure the parser to use the provided time zone as a default, ie. when a timezone is not already provided in the date? This way, dates that are explicit about the timezone, eg.

• "2012-04-21T18:25:43-05:00"
• "2012-04-23T18:25:43.511Z"

would not be moved, while dates that don't specify a timezone, eg.

• "2012-01-01"
  would be moved?

This seems to be possible by replacing parser.parseMillis(date); with parser.withZone(timeZone).parseMillis(date); (didn't try).

I think we should not try to move numbers of milliseconds since Epoch either, since Epoch is the same instant on all timezones.

[dadoonet]

@jpountz PR updated

[jpountz]

I think we need to document that it is only applied for dates that don't make the timezone explicit?

[dadoonet]

They'll get a clean exception in that case :) But Yes I can add a note saying that they can't mix things.

[dadoonet]

@jpountz Updated :)

[jpountz]

I just tried it and didn't get any error, the time zone was just ignored (which is fine I think)

[jpountz]

@dadoonet Just played with the pull request, seems to work fine. I left a couple of minor comments but other than that it looks good to me!

[dadoonet]

@jpountz thanks for the comments. Just updated my branch.

I'll rebase on master and run the full tests again.

Do you think it should go in other branch than master and 1.4?

[jpountz]

+1 to push, this looks great!

Do you think it should go in other branch than master and 1.4?

master and 1.4 sound good to me. This is a new feature, so it doesn't really make sense to push it to older branches.

[dadoonet]

I guess I need to update doc with a "coming in 1.4" :)

[dadoonet]

pushed in master (873a45e) and 1.x (2c0db1f)

[mewwts]

Hi, I've opened #9814 because I can't seem to get this to work with rounding in date math. Is this expected behaviour?