We rely on the data being sorted in the sum. This is currently usually the case but it's not guaranteed by the service.
If we have missing data this can be really off, depending on the cause of the missing data. We currently effectively treat NaNs as zeroes and forward-fill gaps in case we use raw data. This is inconsistent and I think we should just forbid resolution of Nones (although this wouldn't really fill gaps in the current version of the service, but in future only).
I think the start time of the CumulativeEnergy should be the timestamp of the first sample. The end time I think is fine if we always assume resampled data, otherwise we would need to adjust it too.
I realized some unrelated things though:
Nones (although this wouldn't really fill gaps in the current version of the service, but in future only).CumulativeEnergyshould be the timestamp of the first sample. The end time I think is fine if we always assume resampled data, otherwise we would need to adjust it too.Originally posted by @cwasicki in https://github.com/frequenz-floss/frequenz-reporting-python/pull/12#pullrequestreview-2341316106