The task is not solvable in general using scheduled task. For example, you have 3 adjacent rows like ('01:00', 123456789), ('01:10', 123456), ('01:11', 234567). You cannot guarantee that the second reboot does not occur between 2nd and 3rd rows.
You must use permanently executed task (service) which saves both current counters and some UID unique enough (for example, task starting timestamp). You may say that such UID may be stored into the registry with another task... maybe. But you must guarantee that it is saved before the most first scheduled execution. You must have static base timestamp. When you have uptime only you cannot define what is the base - so you must store created_at timestamp too.
If you can receive both current system uptime and current network statistic then try to save them. This allows you to define the groups of rows in which you must select one row with max. traffic amounts. But such scheme needs to perform the base timestamp calculation for each row during the statistic retrieving - so it is more reasonable to calculate and to store not system uptime but system starting timestamp.
Moreover, I'd recommend to compare calculated timestamp and prev. row timestamp, and, if they're close enough then use the value from prev. row.
Check this solution:
WITH dates AS (
SELECT DISTINCT "collected at"::DATE "date"
FROM "network utilization"
raw AS (
t2."system starting timestamp" sst,
MIN("number of byte sent since startup") min_snt,
MAX("number of byte sent since startup") max_snt,
MIN("number of byte received since startup") min_rcv,
MAX("number of byte received since startup") max_rcv
FROM dates t1
JOIN "network utilization" t2 ON t1."date" = t2."collected at"::DATE
GROUP BY 1,2
per_session AS (
max_snt - COALESCE(LAG(max_snt) OVER (PARTITION BY sst ORDER BY "date"), 0) sent,
max_rcv - COALESCE(LAG(max_rcv) OVER (PARTITION BY sst ORDER BY "date"), 0) received
GROUP BY "date"
ORDER BY 1;
https://dbfiddle.uk/?rdbms=postgres_12&fiddle=0453fe758a160ccbc617cce65830f40a with some comments/explanations.