clock synchronization
Every computer has its own little clock ticking away, and here is the surprise: no two of them agree. Cheap clocks drift — one gains a few seconds a day, another loses a few — so within a network, each machine's idea of "now" is slightly different. That sounds harmless until you try to compare events across machines: did the order on server A happen before or after the payment on server B? If their clocks disagree, the timestamps lie. Clock synchronization is the effort to bring all those independent physical clocks close to agreement on the real wall-clock time.
The most common tool is NTP, the Network Time Protocol. Roughly, your machine asks a more accurate time server "what time is it?", notes when it sent the question and when the answer arrived, and uses the round-trip time to estimate how long the reply spent in transit. It then adjusts its own clock toward the server's time, correcting for that estimated network delay. Rather than jerking the clock backward (which could make time appear to go in reverse and break programs), the OS usually slews it — speeds it up or slows it down gently until it catches up. Servers form a hierarchy down from very precise reference clocks (atomic clocks, GPS) at the top.
Why it matters, and the hard limit: synchronized physical clocks are genuinely useful — for log timestamps, for security certificates that expire, for scheduling. But you can never make them perfectly equal, because you can never know the exact one-way network delay (you only measure the round trip, and the two directions may differ). So there is always a residual uncertainty of at least a few milliseconds. This is precisely why distributed systems often abandon physical time for ordering events and instead use logical clocks (like Lamport clocks), which capture cause-and-effect order without needing synchronized wall-clock time at all.
Your laptop's clock has drifted 4 seconds slow. It asks an NTP server the time; the round trip takes 40 milliseconds, so it estimates the reply was about 20 ms old on arrival, adds that, and gently slews its clock forward over the next few seconds rather than jumping it, so no program ever sees the time appear to go backward.
Estimating the network delay to nudge a drifting clock toward true time — but never perfectly.
Synchronized clocks are close, never exact, because the one-way delay is unknowable. So never rely on physical timestamps from different machines to decide the precise order of two close events — for that, use logical clocks.