Forum Discussion
Is there a bug in the make-series function or am I usingit wrong ?
Ok, If I modify the timestamp boundaries in the make-series function, I get the expected results.
However, you need to make sure that the offsets are large enough. Modifying them by subtracting / adding one second is not enough.
If I change the fromDate to 2023-03-29T00:00 and the toDate to 2023-03-30T22:00:00 in the make-series function like this:
VesselTelemetry
| where Timestamp >= todatetime('2023-03-29T08:38:03.6817196Z') and Timestamp < todatetime('2023-03-30T08:38:03.6817202Z')
| where VesselId == '9728693' and TelemetryTag == 'stw' and TelemetryQuality >= 192
| order by Timestamp
| summarize arg_max(Timestamp, telemetryValue = TelemetryValue_Double), eventCountValue = count() by bin(Timestamp, totimespan('1.00:00:00'))
| project telemetryValue, eventCountValue, Timestamp
| make-series telemetrySeries = max(telemetryValue) default = double(null), eventCountSeries = max(eventCountValue) on Timestamp from todatetime('2023-03-29T00:00:00Z') to todatetime('2023-03-30T22:00:00') step totimespan('1.00:00:00')
Then, I get these results:
| telemetrySeries | eventCountSeries | Timestamp |
| [12,11.6] | [7841,5815] | ["2023-03-29T00:00:00.0000000Z","2023-03-30T00:00:00.0000000Z"] |
Frederik-Gheysels While the start of time is inclusive, end of time is non inclusive.
You created make-series on Timestamp column which has min value of 2023-03-29T00:00:00 but in your KQL query, you used 2023-03-29T08:38:03.6817196Z. so 12 and 7841 will not be included in the output.
Your second query is correct since it included time less than the min timestamp in your table and a little more than the max timestamp.