Using System.currentTime in distributed service architecture?

Question

I have two services, service A and service B.

I call a method doStuff() on service B and it creates an entry in a database with the system.CurrentTime() on the computer running B code at the time.

I call a method compareThings() on service A and it queries the service B and pulls the entry I just added and takes the timestamp field, call it tsFromB. Now, I want to check system.CurrentTime() - tsFromB.

My question is, if a difference of 1 minute between computer clock differences matters a lot, is system.CurrentTime() - tsFromB from the computer running Service A a good choice to make? Would this be correct?

Answer 1

You cannot trust individual computer clocks for many reasons.

In response to your question in the comment section, I will share an excerpt from Martin Kleppmann's book, Designing Data-Intensive Applications from his section on unreliable clocks.

• The quartz clock in a computer is not very accurate: it drifts (runs faster or slower than it should). Clock drift varies depending on the temperature of the machine. Google assumes a clock drift of 200 ppm (parts per million) for its servers, which is equivalent to 6 ms drift for a clock that is resynchronized with a server every 30 seconds, or 17 seconds drift for a clock that is resynchronized once a day. This drift limits the best possible accuracy you can achieve, even if everything is working correctly.
• If a computer’s clock differs too much from an NTP server, it may refuse to synchronize, or the local clock will be forcibly reset. Any applications observing the time before and after this reset may see time go backward or suddenly jump forward.
• If a node is accidentally firewalled off from NTP servers, the misconfiguration may go unnoticed for some time. Anecdotal evidence suggests that this does happen in practice.
• NTP synchronization can only be as good as the network delay, so there is a limit to its accuracy when you’re on a congested network with variable packet delays. One experiment showed that a minimum error of 35 ms is achievable when synchronizing over the internet, though occasional spikes in network delay lead to errors of around a second. Depending on the configuration, large network delays can cause the NTP client to give up entirely.
• Some NTP servers are wrong or misconfigured, reporting time that is off by hours. NTP clients are quite robust, because they query several servers and ignore outliers. Nevertheless, it’s somewhat worrying to bet the correctness of your systems on the time that you were told by a stranger on the internet.
• “Leap seconds result in a minute that is 59 seconds or 61 seconds long, which messes up timing assumptions in systems that are not designed with leap seconds in mind. The fact that leap seconds have crashed many large systems shows how easy it is for incorrect assumptions about clocks to sneak into a system. The best way of handling leap seconds may be to make NTP servers “lie," “by performing the leap second adjustment gradually over the course of a day (this is known as smearing), although actual NTP server behavior varies in practice.
• “In virtual machines, the hardware clock is virtualized, which raises additional challenges for applications that need accurate timekeeping. When a CPU core is shared between virtual machines, each VM is paused for tens of milliseconds while another VM is running. From an application’s point of view, this pause manifests itself as the clock suddenly jumping forward.
• “If you run software on devices that you don’t fully control (e.g., mobile or embedded devices), you probably cannot trust the device’s hardware clock at all. Some users deliberately set their hardware clock to an incorrect date and time, for example to circumvent timing limitations in games. As a result, the clock might be set to a time wildly in the past or the future.

Of course, if you decide to get your clock data from another distributed component, then you go again into the classical problems of distributed computing, like what happens if that service that gives you the time is down, or inaccessible, or too slow, etc, etc. And this applies also to the database. Provided that one deals with that, using this global, shared entity would somewhat solve the problem.

Answer 2

Have you ever heard of NTP(Network Time Protocol) protocol? It is for the time synching of computers on a network to prevent such problems. I advise you to use it instead of solving the side effects of not using such choices. For more information you can follow below links:

NTP

NTP wiki

Answer 3

Normally I would not use the timestamp from Computer A or B for such cases. I would use the current time from the database.