...
[13:12:12 CDT(-0500)] <drewwills> it does seem to be related to timezone shift of some ilk
[13:12:31 CDT(-0500)] <drewwills> i'm getting "java.lang.AssertionError: expected:<158> but was:<0>"
[13:12:38 CDT(-0500)] <drewwills> so no hits
[13:12:56 CDT(-0500)] <EricDalquist> right
[13:13:12 CDT(-0500)] <drewwills> but if I change: final DateTime queryEnd = queryStart.plusDays(1).minusSeconds(1); >>>> final DateTime queryEnd = queryStart.plusDays(2).minusSeconds(1);
[13:13:28 CDT(-0500)] <drewwills> (thereby extending the query by 24 hrs)
[13:13:55 CDT(-0500)] <drewwills> i still get a mismatch in those numbers, but it's no longer zero
[13:14:03 CDT(-0500)] <EricDalquist> ok
[13:14:18 CDT(-0500)] <drewwills> so events are going in, they're just going in at instants that are outside the query range
[13:14:28 CDT(-0500)] <drewwills> also...
[13:14:41 CDT(-0500)] <drewwills> the test is preparing the range in UTC
[13:15:15 CDT(-0500)] <drewwills> but the query code (not in test – in src/main/java) appears to be querying in local time
[13:15:40 CDT(-0500)] <drewwills> JpaBaseAggregationDao.getAggregations
[13:16:47 CDT(-0500)] <EricDalquist> well that would use whatever the TZ is on the start/end objects that are passed in
[13:16:57 CDT(-0500)] <EricDalquist> I think
[13:17:50 CDT(-0500)] <drewwills> that's not what i'm observing, i think
[13:18:26 CDT(-0500)] <drewwills> it seems that "final LocalDate startDate = start.toLocalDate();" gives you a calendar date w/o any TZ info
[13:18:53 CDT(-0500)] <EricDalquist> right
[13:18:56 CDT(-0500)] <EricDalquist> but if you look in joda time
[13:19:08 CDT(-0500)] <EricDalquist> it creates that local date using the TZ of the start DateTime object
[13:19:15 CDT(-0500)] <drewwills> and "start.toLocalTime()" gives you an hour:min:sec of the day, also without any TZ attached
[13:20:35 CDT(-0500)] <drewwills> you can't ask a LocalDate the question getTimezone()
[13:20:44 CDT(-0500)] <EricDalquist> right
[13:20:58 CDT(-0500)] <EricDalquist> but if you look at how toLocalDate is implemented
[13:21:00 CDT(-0500)] <drewwills> no method for that, which leaves me to think it's "detached" from the concept of timezone
[13:21:02 CDT(-0500)] <EricDalquist> it does:
[13:21:46 CDT(-0500)] <EricDalquist> new LocalDate(start.getMillis(), start.getChronology());
[13:21:55 CDT(-0500)] <EricDalquist> and chronology includes the TZ
[13:22:14 CDT(-0500)] <EricDalquist> so it is creating that LocalDate using the TZ of the start DateTime
[13:23:52 CDT(-0500)] <drewwills> https://gist.github.com/drewwills/5556362
[13:24:51 CDT(-0500)] <drewwills> i end up with "start.toLocalTime()=00:00:00.000" and "end.toLocalTime()=23:59:59.000" (no TZ adjustment)
[13:25:53 CDT(-0500)] <drewwills> NB: that was after I changed from UTC >> local time in the test
[13:26:01 CDT(-0500)] <drewwills> i should undo that and re-run it
[13:28:19 CDT(-0500)] <drewwills> there – updated