uPortal IRC Logs-2013-05-10

Owned by Apereo Infrastructure
Last updated: May 10, 2013
2 min read

[13:11:25 CDT(-0500)] <drewwills> Are you there EricDalquist? I've done some research on the aggr test failures

[13:11:32 CDT(-0500)] <EricDalquist> hi

[13:11:34 CDT(-0500)] <EricDalquist> whats up?

[13:11:50 CDT(-0500)] <drewwills> I've made some observations, but not sure I know it intimately enough to choose a path

[13:11:58 CDT(-0500)] <EricDalquist> ok

[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