Data written with different time precision when using "to" function in a task

[Silvia Corrado]

Hello,
I have a task executed each 10 minutes, which is in charge to sum several values, stored in several measurement (like cpu_global = cpu1 + cpu2 + cpu3....) and save the result through the "to" function, into a destination bucket.
The sum is correctly computed and saved in destination bucket, but it seems that the time precision is not always the same.
What makes me think this is that when I'm trying to retrieve values from the measurement "cpu_global", values are returned in different tables and the only way to get them in the same table is to "truncate" the _time column to put all the records at the same time unit r with _time: date.truncate(t: r._time, unit: 1s)).

What is the expected behavior for "to" function (or maybe (or am I using the "to" function in the correct way?) How to ensure the time precision in a task and avoid this kind of issue ?

The code for my task :

from(bucket: "test")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement =~ /cpu.*/)
|> aggregateWindow(every: 10m, fn: sum, createEmpty: true)
|> group(columns: ["_time"], mode: "by")
|> sum(column: "_value")
|> group()
|> map(
fn: (r) => ({r with _measurement: "cpu_global", _field: "bla", units: "bla", location: "bla"}),
)
|> keep(
columns: [
"_time",
"_measurement",
"_value",
"_field",
"units",
"location",
],
)
|>to(bucket: "destination")

1 ) Query to get the result :
from(bucket: "destination")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement == "cpu_global")

==> data splitted in table 0 and table 1 and strangely graphed

2 ) Query with the truncated :

import "date"
from(bucket: "destination")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement == "cpu_global")
|> map(fn: (r) => ({ r with _time: date.truncate(t: r._time, unit: 1s) }))
|> sort(columns: ["_time"])

==> only one table and graph is OK

[github-actions]

This issue has had no recent activity and will be closed soon.