[11:40:52 CDT(-0500)] <athena> hey EricDalquist - is there a way to request a list of potential aggregation intervals within a time period?
[11:41:03 CDT(-0500)] <athena> seems like we must have existing logic for that somewhere
[11:42:52 CDT(-0500)] <EricDalquist> hrm
[11:43:02 CDT(-0500)] <EricDalquist> so like
[11:43:21 CDT(-0500)] <EricDalquist> from 5:03am to 5:55am give me a list of the 5 minute interfals
[11:44:53 CDT(-0500)] <athena> yeah
[11:45:07 CDT(-0500)] <athena> i think we need that to be able to know which intervals are missing so we can add zeros
[11:46:15 CDT(-0500)] <EricDalquist> I don't think we have that yet
[11:46:27 CDT(-0500)] <EricDalquist> but it would be something else to add to AggregationIntervalHelperImpl
[11:46:30 CDT(-0500)] <athena> ok
[11:46:36 CDT(-0500)] <athena> hmm.
[11:46:48 CDT(-0500)] <EricDalquist> are you looking at that class right now?
[11:46:54 CDT(-0500)] <athena> no, but i can pull it up
[11:47:01 CDT(-0500)] <athena> how does our current code calculate intervals to do aggregation in the first place?
[11:47:12 CDT(-0500)] <EricDalquist> public AggregationIntervalInfo getIntervalInfo(AggregationInterval interval, DateTime date)
[11:47:29 CDT(-0500)] <EricDalquist> so you say something like getIntervalInfo(FIVE_MINUTE, date)
[11:47:47 CDT(-0500)] <EricDalquist> and it figures out the start/end
[11:47:54 CDT(-0500)] <EricDalquist> then loads the dimension objects
[11:48:19 CDT(-0500)] <athena> ah
[11:48:24 CDT(-0500)] <athena> so it just does one at a time
[11:48:28 CDT(-0500)] <EricDalquist> yeah
[11:48:35 CDT(-0500)] <athena> ok
[11:48:37 CDT(-0500)] <athena> i'll take a look
[11:48:38 CDT(-0500)] <EricDalquist> it shouldn't be hard to do what you want
[11:48:44 CDT(-0500)] <EricDalquist> for all intervals except CALENDAR_QUARTER ACADEMIC_TERM
[11:48:51 CDT(-0500)] <EricDalquist> you can do interval.getDateTimeFieldType()
[11:48:57 CDT(-0500)] <athena> i'd love to get a sample report in for 4.0.5, but right now thinking that's probably a stretch
[11:49:06 CDT(-0500)] <EricDalquist> I might be able to help
[11:49:10 CDT(-0500)] <athena> ok
[11:49:11 CDT(-0500)] <EricDalquist> and use the joda APIs to increment the date
[11:49:21 CDT(-0500)] <athena> makes sense
[11:49:23 CDT(-0500)] <athena> i'll take a look
[11:49:37 CDT(-0500)] <EricDalquist> for CALENDAR_QUARTER, ACADEMIC_TERM you have to go to the DB
[11:49:42 CDT(-0500)] <athena> right
[11:49:49 CDT(-0500)] <athena> that makes sense
[12:02:43 CDT(-0500)] <EricDalquist> athena: I'm playing with some ideas for fillInBlanks
[12:03:39 CDT(-0500)] <athena> oh, cool
[12:03:55 CDT(-0500)] <athena> i'm stumbling over figuring out how to actually add a DurationFieldType to a date
[12:04:32 CDT(-0500)] <EricDalquist> I think this works
[12:04:33 CDT(-0500)] <EricDalquist> final DateTime thisDate = timeDimension.getTime().toDateTime(dateDimension.getDate());
[12:04:37 CDT(-0500)] <EricDalquist> haven't actually tested it though
[12:05:38 CDT(-0500)] <athena> a little more context?
[12:06:03 CDT(-0500)] <EricDalquist> oh sorry]
[12:06:06 CDT(-0500)] <EricDalquist> I was confused
[12:06:21 CDT(-0500)] <athena> actually i wonder if we need the duration field at all
[12:06:31 CDT(-0500)] <athena> so some of this depends on how boundaries are handled
[12:07:06 CDT(-0500)] <EricDalquist> instant.property(dateTimeFieldType).addToCopy(1);
[12:07:08 CDT(-0500)] <EricDalquist> that might do it
[12:07:11 CDT(-0500)] <athena> depending on the implementation i guess we could do something like loop through calling getIntervalInfo, setting the next call's DateTime parameter to the end time of the last interval returned
[12:07:34 CDT(-0500)] <EricDalquist> hrm
[12:07:46 CDT(-0500)] <athena> it seems like maybe that makes more sense than using the date field?
[12:07:47 CDT(-0500)] <EricDalquist> that's a good point
[12:07:49 CDT(-0500)] <EricDalquist> yeah
[12:07:53 CDT(-0500)] <athena> i'll try that
[12:08:04 CDT(-0500)] <EricDalquist> AggregationIntervalInfo has the start (inc) and end (exc)
[12:08:04 CDT(-0500)] <athena> should work if the end date isn't considered part of the period
[12:08:10 CDT(-0500)] <athena> ok, that's what i figured
[12:08:12 CDT(-0500)] <athena> so that should work
[12:08:15 CDT(-0500)] <EricDalquist> so if you ask for the AggregationIntervalInfo for the end DateTime of the previous AggregationIntervalInfo
[12:08:25 CDT(-0500)] <EricDalquist> you should get the new start that you want
[12:08:27 CDT(-0500)] <athena> assuming that intervals always share boundaries
[12:08:29 CDT(-0500)] <athena> yeah
[12:08:49 CDT(-0500)] <EricDalquist> well that's why you need to ask and not just use the end explicitly :/
[12:08:56 CDT(-0500)] <EricDalquist> but I believe they must always share boundaries
[12:10:02 CDT(-0500)] <athena> need to ask what?
[12:10:23 CDT(-0500)] <EricDalquist> getIntervalInfo
[12:10:27 CDT(-0500)] <athena> ah
[12:10:35 CDT(-0500)] <athena> some chance maybe that quarters don't share boundaries
[12:10:43 CDT(-0500)] <athena> or academic terms, more like
[12:10:52 CDT(-0500)] <athena> but we were planning to handle those via db calls anyway
[12:11:40 CDT(-0500)] <EricDalquist> nope
[12:11:46 CDT(-0500)] <EricDalquist> quarters require they touch
[12:11:55 CDT(-0500)] <EricDalquist> and I think terms do as well
[12:12:05 CDT(-0500)] <EricDalquist> oh there is also EventDateTimeUtils
[12:12:08 CDT(-0500)] <EricDalquist> which has some static helper methods
[12:14:53 CDT(-0500)] <athena> good to know, thanks!
[12:17:21 CDT(-0500)] <EricDalquist> https://gist.github.com/2360656
[12:17:24 CDT(-0500)] <EricDalquist> in theory that works
[12:17:31 CDT(-0500)] <EricDalquist> unit tests would probably be a good idea 
[12:17:59 CDT(-0500)] <EricDalquist> hrm
[12:18:02 CDT(-0500)] <EricDalquist> apparently I was bad
[12:18:10 CDT(-0500)] <EricDalquist> and didn't write any tests for AggregationIntervalHelperImpl 
[12:19:27 CDT(-0500)] <athena> cool, i think we're on the same page - this looks close to what i've sketched out
[12:19:32 CDT(-0500)] <athena> and i'll write some tests for this at least
[12:23:49 CDT(-0500)] <athena> and actually you did write tests it turns out - that class just didn't get renamed
[12:24:28 CDT(-0500)] <EricDalquist> oh
[12:24:29 CDT(-0500)] <EricDalquist> hah
[12:24:46 CDT(-0500)] <EricDalquist> that's good
[12:24:52 CDT(-0500)] <EricDalquist> I was feeling really bad for not writing a test for that class
[12:26:17 CDT(-0500)] <athena>
[12:26:20 CDT(-0500)] <athena> i'll add tests for this
[12:26:22 CDT(-0500)] <athena> and can rename it
[12:26:27 CDT(-0500)] <EricDalquist> sounds good
[13:02:20 CDT(-0500)] <EricDalquist> !@#$!@ timezones 
[13:02:30 CDT(-0500)] <EricDalquist> another unit test failing on bamboo because I forgot to setup the TZ
[13:29:06 CDT(-0500)] <athena> eeoops
[13:29:15 CDT(-0500)] <athena> writing unit tests for this turns out to be a pian
[13:29:38 CDT(-0500)] <athena> need something for date dimensions, time dimensions, etc.