A Practical Guide to Time for Developers — The Complete Series
Time looks simple until you have to trust it.
We use timestamps everywhere: logs, APIs, databases, schedulers, certificates, metrics, traces, distributed systems, industrial systems. But the moment you start asking basic questions — what exactly is this timestamp measuring? which clock produced it? how does one machine keep time? how do many machines agree on it? — the topic becomes much deeper than it first appears.
This series was my attempt to build a practical mental model of time for developers from first principles all the way down to Linux clocks, NTP, PTP, PHCs, and synchronization tools.
If you want one entry point into the whole topic, this is it.
What this series covers
This series is built as a path:
first, what time actually means in software
then, how one computer keeps time
then, how many computers synchronize time
and finally, how Linux represents all of this in practice
The goal was never to produce a dry reference manual.
The goal was to make time feel understandable.
Not just “I know NTP exists,” but a real working model of:
what time is
how clocks drift
why synchronization is hard
why timestamp location matters
and how Linux exposes all of this in real systems
The full reading path
This is the foundation.
If you ever used timestamps without being fully sure what they really mean, start here.
This part covers the basic language of the topic: what time means in software, why timestamps are not “time itself,” what role standards and agreements play, and why the whole subject is more subtle than it first appears.
This is the part that gives you the mental vocabulary for everything that comes later.
Once the theory is clear, the next question is obvious:
How does one computer actually keep time?
This part moves inside the machine. It covers the clocks and mechanisms Linux uses to track time, including the RTC, system time, counters, and the distinction between different clock sources and time domains.
If Part 1 explains what time means, Part 2 explains how a single system turns that idea into something measurable and usable.
A single computer can keep time locally.
A distributed system has a harder problem: many machines must keep time together.
This part is about synchronization. Why simply setting clocks once does not work. Why drift makes synchronization a continuous process. How NTP and PTP approach the problem. And why the quality of synchronization depends not only on the protocol, but also on where timestamps are taken.
This is where time stops being a local machine detail and becomes a systems problem.
This is the practical payoff.
It turns the concepts from the whole series into the Linux view of the world:
RTC
system clock
PHC
NTP
PTP
ptp4l
phc2sys
and the usual synchronization paths between them
This is the compact field guide version — the part you can actually bookmark and return to when you need to inspect, operate, or debug time synchronization on Linux.
Interactive visuals and supporting materials
Along the way, I also started building visual and interactive explanations for some of the harder ideas, such as:
clock drift
synchronization by timestamp exchange
NTP principles
PTP principles
software vs hardware timestamping
I want this series to be more than just text. Time is easier to understand when you can see it move.
Who this series is for
This series should be useful if you work with:
backend or distributed systems
Linux and infrastructure
observability and logs
event ordering
industrial or measurement systems
networking
NTP/PTP
or just any system where timestamps need to be trusted
In other words: if time can break your system, this topic is worth understanding properly.
Why I wrote this
Time is one of the most used and least understood parts of software.
Most of us interact with it every day, but only occasionally stop to ask what is actually happening underneath. I wanted to fix that for myself first — and then turn that learning process into something practical and usable for other engineers.
This series is the result.
Final note
If you made it through the whole series, you did not just read a few posts about clocks.
You built a real mental model of time in computing — from first principles, to clocks inside a machine, to synchronization across networks, to the actual Linux entities and tools that make it work in practice.
That already puts you ahead of most engineers who touch these systems.
You now know enough to stop treating time as a mysterious background feature and start seeing it for what it really is:
infrastructure, measurement, coordination, and engineering.
Bookmark this page. I’ll keep it as the main entry point for the whole series.