Here’s something as simple as a distributed build system (using Make) can fail because of a ~5-minute clock skew. Here’s how…
Consider a distributed make system where your source files live on a client machine and the compiled object files live on a server. If the client clock lags behind the server clock by even a few seconds, something subtle happens.
Client clock: 10:00:00 (lagging)
Server clock: 10:00:05 (ahead)
1. Edit util.c at client time 10:00:00
2. util.o on server has timestamp 10:00:03
3. Make compares: util.o > util.c
4. recompilation is skipped
5. The new changes vanish from the build
When you edit a source file, your client timestamps it with its current time. But the object file on the server already has a later timestamp than the server’s clock. When make runs and compares these timestamps, it sees the object file as newer than your source file.
The result? Make skips recompilation entirely. Your changes silently disappear from the build.
Now you see why Clock Synchronization is one of the most interesting and important problems out there :) It is a rabbit hole in itself. Read about it when you want an adrenaline rush! Sorry, a little exaggeration there.