Hi,
Considering the data aggregation scenario of the Time Series API, I noticed a strange behavior.
When passing a time period defined by “start” and “end”, with aggregation “NONE”, a certain amount of data points is returned within that time interval. When using the “COUNT” aggregation for the same time period, regardless of the resolution, it should return the same count of data points.
However, this does not happen for all cases. In some cases, the “COUNT” of data points returned is greater than the number of data points in the “start”/“end” interval that was passed in the request. However, depending on the resolution that is passed, the “end” is automatically changed, causing the requested data period to be altered, and thus the count is not equal.
To address this, I created a workflow that allows me to verify this behavior, in which depending on the configured resolution, the “end” of the request is changed, affecting the API response.
In my understanding, it should be consistent with the “start” and “end” passed in the request.
timeseries-test-develop.flow (18.2 KB)
Thanks!
1 Like
Hi @Vander_Maziero !
Thanks for bringing this up and taking the time to create a demo workflow. We’re taking a look and will get back with you shortly.
Sorry for the delay on this; we had a good idea on what was going on here but wanted to run it past a member of our engineering team who was on vacation last week.
Given a resolution, we attempt to align that resolution to time buckets that align with the clock/calendar. For example, if you request data from 4:55pm on April 1 through 8:19am April 11, with a resolution of 24 hours, we will align those resolution buckets to the start of each day GMT. Doing so means we need to adjust the duration to avoid “partial buckets” of time, where a resolution point would only represent a portion of the day. You will notice in the API responses in your workflow that we do return the actual start and end datetimes for the dataset, which differs from the requested start and end datetimes in order to fit the buckets.
If the provided resolution is not divisible into days, hours, minutes, or seconds, we do return extended buckets as described above. For example, if you change every one of your resolutions in the example flow to add one millisecond, you will see that the returned data matches the requested start and end times and the counts are consistent.
Hopefully this helps. I understand it’s a bit unusual so please let us know if you have any questions.
Thank you for your response.
I suspected that might be the case, and I will make sure to check and always try to use resolutions that close on whole intervals to avoid the shifting of the last interval.
