A while ago we have hardened our timing in the metric reporters - #1106
Suprisingly we have not thought about the timing we have in the python code itself as time.time() is also dependent
on the OS clock source and can shift when for instance NTP decides the clock has drifted too much, or a DST time change / leap second is happening.
This issue shall explore if we want to move to time.monotonic()
Probably using the same approach as we did in #1106 where we first align the monotonic clock and then only use monotonic created timestamps after.
@ribalba
@davidkopp
Thougths on this? Did I overlook something in this idea?