The reason is that I'm a complete bozo who saw the number range from very small to very large and assumed that the reset was midnight, not a reboot. So I retract my claim that there could be a midnight bug. Hopefully I'm not banned from these forums, but if you want to give me a short ban, I'd accept it. A week seems fine.
But what I said about epoch times, I still stand by. I remain confident that epoch times look like the have high resolution, but because they are based on unix time, which is rounded to the nearest second, they can't return fractional numbers (of seconds), and therefore are of limited use for timing things, despite the fact that they return high precision real numbers. And you did say you used epoch times, so I was implying that there might be a bug in your code. However you have since re-stated that you are not using epoch times, but using SECONDS(), so that means you won't have a bug.
So for example, the wiki says this about JD():
A JulianDate (JD) is days (and fractions of days) since January 1, 4713 BC Greenwich noon.
And if you look at the results of JD(), you get a number like:
2460477.65442131
By looking at that, you can see 8 decimal places, so one might think that the precision of JD() is one hundred millionth of a day, which would be "24 times 60 times 60"/100000000=0.000864. But that's very misleading because the true resolution of JD() is 1.0 seconds, not 0.000864 seconds.
In my opinion, JD() should return no more than three decimal points of accuracy, or the wiki for JD() should state that only 3 decimal places have any meaning.
If you try this macro, you will realize that JD() does not resolve times to more than one second:
If you study the output, you will realize that JD() never gives 8 decimal places of accuracy, just three decimal places.