1
$\begingroup$

if UTC is universal, what drawbacks does it have in using it in a distributed system to coordinate events or use it as a global objective reference clock?

isn't it right to just use UTC to timestamp every message to order messages without using lamport logical clocks!

$\endgroup$
4
  • $\begingroup$ If you can guarantee a bound on the desynchronization of the clocks, then you can indeed tell if events are "simultaneous", else what is the ordering. $\endgroup$ Jun 6, 2022 at 7:50
  • $\begingroup$ @YvesDaoust but if they use UTC they don't have to synchronize their clocks, they will request the timestamp from the central server, get that timestamp add the delay (if its synchronous network) and now you have consensus. $\endgroup$
    – ezio
    Jun 6, 2022 at 8:58
  • 3
    $\begingroup$ You confuse UTC which is a time reference convention, and clock synchronization on a network. Perfect synchronization is never possible, and using UTC does not help. $\endgroup$ Jun 6, 2022 at 9:07
  • $\begingroup$ Even if you have perfect synchronization of clocks in UTC, using UTC timestamp only may lead to "overordering" or wrong logical ordering. For example, event EA at process A happened at UTC TA and event EB at process B happened at UTC TB, where TA is earlier than TB. However, all effects of EA reach process B after TB, if any of them does reach process B at all. Then from the point of view of process B, it should be better to consider EA happens after EB logically. Locally, the logical order may be easier to operate and more significant for understanding. $\endgroup$
    – John L.
    Jun 11, 2022 at 16:08

1 Answer 1

1
$\begingroup$

In a distributed system, achieving perfect time synchronization among all nodes is often impossible. Lamport logical clocks are one way to deal with this problem.

I presume that by "use UTC to timestamp" you are assuming that you will use a timestamp. The problem is that machines' clocks usually aren't perfectly synchronized, so machine A might give a timestamp of 5:00:00.00 and machine B might give a timestamp of 5:00:00.13, but the event on B might actually have happened first even though the timestamp appears to be later, because B's clock isn't synchronized to A's clock.

See also https://en.wikipedia.org/wiki/Logical_clock.

$\endgroup$
8
  • $\begingroup$ but if they use UTC they don't have to synchronize their clocks, they will request the timestamp from the central server, get that timestamp add the delay (if its synchronous network) and now you have consensus. $\endgroup$
    – ezio
    Jun 6, 2022 at 8:57
  • $\begingroup$ @ezio, I've already told you the reason: in most systems, there is no way to achieve perfect time synchronization. No matter how many times you use the word "UTC", you can't assume all nodes have perfect time synchronization. To start to get a sense of why, you might ponder how you would ensure perfect time synchronization in a large distributed system, and how you will make it resilient to failures (loss of network connectivity, individual nodes being down). $\endgroup$
    – D.W.
    Jun 6, 2022 at 9:02
  • $\begingroup$ Or, to put it another way: in most systems, "UTC" is a fiction that can't be measured exactly. I apologize for my failures in communication -- I can see I'm probably not explaining clearly. $\endgroup$
    – D.W.
    Jun 6, 2022 at 9:03
  • 1
    $\begingroup$ You have two problems: One, if you have one event in London and one in Los Angeles, "which one happened first" is not well defined (Thank you Mr. Einstein. You got us into a fine mess). Two, even if it was well defined in principle, there will be events so close together that you can't determine which one happened first. Instead, we use a method that numbers events #1, #2, #3, ..., with a good attempt to make the order consistent with UTC, but what we use is those numbers, not actual UTC. $\endgroup$
    – gnasher729
    Jun 6, 2022 at 10:31
  • $\begingroup$ @D.W. i guess i understand the main flaw in my reasoning, just because i timestamp some event with UTC doesn't mean it objectively is the time that event happened, because the event is created before the timestamp therefore multiple events are seen as concurrent with this one because there is no way to tell which is first before the timestamp, could you please add this to your answer so that i mark it as correct, thank you $\endgroup$
    – ezio
    Jun 11, 2022 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.