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.).