update interval no longer shrinks with recursion

Previously, the endtime-starttime interval being processed by the run_as_update method would shrink by 1 (second) with each recursion. This ultimately broke run_as_update when processing anything other than 1-second data, but it wasn't obvious because we rarely had to actually recurse. There is a little trickery now to ensure that user- provided starttime and endtime are inclusive of the full first (most recent) update interval, while subsequent, calculated, endtimes are set equal to the prior starttime minus specified output_interval (e.g., 'second', 'minute', etc.).

requested review from @jmfee

assigned to @erigler

FYI, @jmfee, this is something I saw while trying to track down the cause of the weird gaps that cropped up when we had communication outages recently. I don't actually expect this MR to fix that issue (which, despite my best efforts, I was never able to reproduce deliberately), but who knows.

@erigler : If this is the cause, a unit test should be able to reproduce the issue, I'll try to review soon

added 1 commit

• 65436427 - Add get_previous_interval method and test

Compare with previous version

@erigler: this definitely looks like a likely cause. I moved the logic to a separate method, added a test, and took a different approach. Feel free to merge if this looks good to you.

resolved all threads

mentioned in commit c0386793

merged