you definitely cannot rely on clocks to determine (reliable) ordering across machines
truetime doesn't provide precise timestamps, each timestamp has a "drift" window
timestamps within the same window have no well-defined order, applications have to take this into account when doing e.g. distributed transactions
> you definitely cannot rely on clocks to determine (reliable) ordering across machines
You can if you consider "unknown/possibly concurrent" also a valid outcome: for any 2 events A and B, True Time can definitely answers whether A is before B, A is after B, or A is possibly concurrent with B.
Agree, and the timestamp comparisons you can make when the windows do not overlap are the basis of the ordering guarantees (across machines, even globally).
They do have a well defined order, just not one based on time.
I don't see how it isn't based on time. They use GPS and atomic clocks to establish the time, establish an uncertainty window, and in Spanner's case will have transactions wait out that uncertainty to guarantee an ordering (globally).
Look up the case where two transactions affecting the same record share a timestamp (or have overlapping error ranges). An non-timestamp tiebreaker determines the order between the two overlapping commits. It is not unlike the pre-agreement on conflict resolution mechanisms for CRDTs.
The context to my first comment included "timestamps within the same window"
Data center/cloud system clocks can be tightly synchronized now in practice. Still never perfect and race conditions abound.
But that doesn't mean you can't rely on a clock to determine ordering, Google popularized a different approach with TrueTime/Spanner: https://cloud.google.com/spanner/docs/true-time-external-con...