> not necessarily exactly equal to the time
I believe it was Poincare who has proven that it's even theoretically impossible to synchronize clocks exactly.
I believe it was Poincare who has proven that it's even theoretically impossible to synchronize clocks exactly.
And with computers it's fussy to get clocks synchronized below a millisecond but not that fussy. You can keep a single computer synchronized down to a single cycle, making timestamps effectively perfect across different parts of it. And then between computers, if you have n latency between them you should be able to get the clocks within n/10, which might as well be perfect for coordination purposes.
If something is possible theoretically, it may not be in practice. But if something is proven to be impossible, it's also impossible in practice.
Note we're not talking about "below a millisecond" or below any other time range (second, minute, month). We're talking about _exactly_.
You can pick reference spot(s) and get it good enough.
> Note we're not talking about "below a millisecond" or below any other time range (second, minute, month). We're talking about _exactly_.
Ah, but we're not talking about exactly. Even when you're going for maximum accuracy, timestamps aren't generated at a particular instant. The gates in the computer coalesce over a cycle or two, if not longer. If you sync down to roughly the nanosecond, you hit max accuracy for CPU timestamps.
Though again, what's wrong with two CPUs that are n light-seconds apart having clocks that differ by at most n/10 seconds? You can't actually prove they aren't synchronized exactly, because of relativity.