Even Google's "now" is still a little fuzzy -- their system doesn't so much define "now" as it defines the uncertainty around "now", which you can take advantag

Even Google's "now" is still a little fuzzy -- their system doesn't so much define "now" as it defines the uncertainty around "now", which you can take advantage of for figuring out ordering. This paragraph (from section 1 of their paper) summarizes it pretty well: > The key enabler of these properties is a new TrueTime > API and its implementation. The API directly exposes > clock uncertainty, and the guarantees on Spanner’s timestamps > depend on the bounds that the implementation provides. > If the uncertainty is large, Spanner slows down to > wait out that uncertainty. ...so really, GPS and atomic clocks aren't for defining "now" they're for providing a keeping the window of uncertainty around "now" to a small value. The value mentioned in the paper for this is "generally less than 10ms", which is pretty good for a large-scale distributed system, but massive in terms of precision timekeeping. It is, after all, an uncertainty that's three orders of magnitude larger than the GPS glitch that started this discussion...