[timf]

> The main reason we can not use system clocks is that system clocks across servers are not guaranteed to be synchronized.

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...

[preseinger]

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

[dikei]

> 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.

[preseinger]

"reliable ordering" usually implies a specific and well-defined order, without concurrent events :)

[timf]

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).

[preseinger]

kind of? not really?

ordering is a logical property which can be informed by physical timestamps, but those timestamps aren't accurately described as "the basis" of that ordering

[erikerikson]

They do have a well defined order, just not one based on time.

[timf]

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).

[erikerikson]

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"