Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

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

Make ValueParser.DateMath aware of timezone setting #12886

Merged
merged 2 commits into from
Aug 19, 2015

Conversation

cbuescher
Copy link
Member

This PR adds a timezone field to ValueParser.DateMath that is
set to UTC by default but can be set using the existing constructors.
This makes it possible for extended bounds setting in DateHistogram
to also use date math expressions that e.g. round by day and apply
this rounding in the time zone specified in the date histogram
aggregation request.

Closes #12278

This PR adds a timezone field to ValueParser.DateMath that is
set to UTC by default but can be set using the existing constructors.
This makes it possible for extended bounds setting in DateHistogram
to also use date math expressions that e.g. round by day and apply
this rounding in the time zone specified in the date histogram
aggregation request.

Closes elastic#12278
@cbuescher cbuescher changed the title Aggregations: Make ValueParser.DateMath aware of timezone setting Make ValueParser.DateMath aware of timezone setting Aug 14, 2015
@jpountz
Copy link
Contributor

jpountz commented Aug 18, 2015

LGTM

@feltnerm
Copy link

💯 ! 🍻 @cbuescher

@feltnerm
Copy link

Any chance this will make it into the latest 1.x? Would be great!

@cbuescher
Copy link
Member Author

@feltnerm Sadly, I wouldn't count on it. Currently working towards 2.0, only major bugfixes get backported to the 1.x branches.

cbuescher added a commit that referenced this pull request Aug 19, 2015
Make ValueParser.DateMath aware of timezone setting
@cbuescher cbuescher merged commit 0fc96ed into elastic:master Aug 19, 2015
@cbuescher
Copy link
Member Author

@jpountz @clintongormley any opinion if this should be backported to 2.0?

@jpountz
Copy link
Contributor

jpountz commented Aug 19, 2015

It's a bug fix and risks look low to me so I would say yes.

@cbuescher
Copy link
Member Author

Also backported to 2.0 branch with 8ba2c9b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants