First, your gist does not use postZone, but preZone. Let me explain the work that was done in 0.19 to improve the rounding with time zones (its tricky).
Lets say you want to round "2012-04-01T04:15:30Z" (which is in UTC what you use in your test: "2012-03-31T20:15:30-08:00").
First, lets do day level rounding with preZone set to -8. "2012-04-01T04:15:30Z" - 8 falls into 2012-03-31, and it will be returned (since postZone defaults to UTC) in UTC, so it all be "2012-03-31T00:00:00Z". So, the result is rounded and returned in UTC (start of month in UTC).
Second, we do hour based rounding with preZone set to -8. "2012-04-01T04:15:30Z" - 8 falls at "2012-03-31T20:15:30", rounding it will mean its "2012-03-31T20:00:00", but, we want to return it in UTC, and the correct rounded time in UTC is: "2012-04-01T04:00:00Z". Here, we do add back the offset, so you get the proper rounded value in UTC.
So, you can just do preZone, and create a new DateTime with the returned time (with UTC time zone). It will be the UTC rounded value that you want. If you want to apply a postZone, then you can, and then you will get the mentioned results, just with the offset applied. So, for day you will get back "2012-03-31T00:00:00-08:00", and for hour you will get back: "2012-04-01T04:00:00-08:00".
I can see where the confusion is coming from, I can add a flag that would make elasticsearch behave to what you expect in the test, though the above behavior is probably what you want. I will add this flag just so we cover all the options of rounding.
On Tuesday, February 28, 2012 at 11:55 PM, Eric Jain wrote:
On Tue, Feb 28, 2012 at 03:02, Shay Banon <email@example.com (mailto:firstname.lastname@example.org)> wrote:
You are not using Joda correctly, check the javadoc for DateTime(long
instant, DateTimeZone zone). The instant is expected to be UTC milliseconds.
What you end up doing is getting back from elasticsearch the time already
with the time zone (-8), and then "apply" it again when creating the
DateTime (another -8).
I expected elasticsearch to always return UTC milliseconds, so that
explains part of the confusion. But even without postZone, it's not
clear to me why I need to add the timezone offset back to the result
to get the expected local time for year/month/day intervals, but not
for hour/minute intervals. See https://gist.github.com/1934291.