zlacker

I don't get how clocks are bad this from the article.

I get that syncing clocks across systems is hard and when it goes awry, unintended consequences are incurred.

>>dustin+(OP)
There is, in fact, a TL;DR at the end:

> If your distributed database relies on clocks to pick a winner, you’d better have rock-solid time synchronization, and even then, it’s unlikely your business needs are served well by blindly selecting the last write that happens to arrive.

>>RickHu+s2
In fact I would recommend GPS calibrated hardware clocks with PTP.

>>ssever+Rc
As last summers negative leap second fiascos demonstrated even a trusted source isnt enough.

>>ssever+Rc
The point is not that time synchronization is inherently bad, only that it's usually not the correct thing for a distributed database to resolve update conflicts with.

>>ssever+Rc
Ok, google.

>>marshr+Aq
Yes I completely agree. I fail to see how anyone would think that using a clock as a source of truth in a distributed system would be in anyway a good idea. As far as PTP it would be too expensive to deploy at large scale which was some of the motivation (i believe) behind truetime.

>>ssever+pU
To be fair, time was considered to provide a pretty universal total ordering up until fairly recently, i.e., 1903.

>>donava+oj
They are when you know that the leap-(nanosecond/second/minute/day) is coming up. When you know it is coming, you can "smear" the time difference over, let's say, the entire year, so when it happens, every system behaves correctly.