How your phone always knows the right time

You almost certainly never set the clock on your phone. You took it out of the box, signed in, and the time was simply correct — correct to the second, in the right zone, and it has stayed correct through every flight, every border and every twice-yearly clock change since. That quiet reliability hides a surprising amount of machinery. A phone is not solving one problem when it shows you the time; it is solving two, and they have almost nothing to do with each other.

Two problems, not one

The first problem is keeping the raw clock accurate. Somewhere inside the device a tiny quartz crystal oscillates, and counting those oscillations is how the phone measures the passing of seconds. Left to itself that crystal drifts — a little every week is normal, more when it runs hot or cold — so a clock that is never corrected slowly wanders away from reality. Keeping it pinned to the true time is a problem of physics and engineering.

The second problem is quite different, and it is the one people underestimate: knowing which time to show. Deciding that London is currently one hour ahead of the sun, or that it will jump forward on the last Sunday in March, is not something you can measure with a crystal or a satellite. It is an administrative fact — a decision made by a government — and it changes. So on top of an accurate underlying clock the phone needs a constantly updated rulebook, telling it how to turn that clock into the wall-clock time for wherever you happen to be standing. The two systems that handle these two problems are worth looking at in turn.

Keeping the clock accurate

The accuracy problem is solved by the Network Time Protocol, or NTP — one of the oldest pieces of internet plumbing still in daily use. The idea is a chain of trust. At the top sit reference clocks: atomic clocks and GPS receivers that keep time to a precision no consumer device could manage. In NTP’s vocabulary those reference sources are called stratum 0. The servers wired directly to them are stratum 1 — the most authoritative timekeepers on the public internet — and below those sit stratum 2, stratum 3 and so on, each layer synchronising to the one above and passing the time downward.

Your phone lives near the bottom of that hierarchy, quietly asking a time server what the time really is and nudging its own clock to match, correcting for the delay the request took to travel there and back. It does much the same over the mobile network, which distributes time from the same kind of high-grade sources. The reference the whole chain is tracking is Coordinated Universal Time, or UTC — the global standard every zone is defined against, which our guide on what UTC is explains in full. Because UTC is occasionally nudged by a leap second to stay in step with the Earth’s slightly irregular rotation, the timekeeping chain has to cope with those too. The upshot is that a cheap phone inherits, second-hand, the accuracy of an atomic clock it will never come near.

Knowing the local rules

An accurate UTC clock still does not tell you what to put on the screen. To turn UTC into the local time in Kolkata or Chicago you need two more pieces of information: the current offset from UTC for that place, and the rule for when — if ever — it shifts for daylight saving. Both are administrative, both differ from country to country, and both change more often than you would expect.

That knowledge lives in a single, shared dataset called the IANA Time Zone Database — you will also see it called tz, tzdata, or the Olson database, after Arthur Olson, who started it. It is the invisible backbone of timekeeping: nearly every operating system, phone, programming language and server ships a copy and refreshes it periodically. Each zone has an identifier like Europe/London or America/New_York, and against that identifier the database records the full history and future of that place’s clocks — the offsets, and the exact dates the daylight-saving changes take effect. When your phone crosses a border and picks up a new network, it selects the matching zone and consults this rulebook to work out the local time. The same data is what lets a world clock show dozens of cities at once, or a daylight saving page tell you whether a given country is on summer time this week.

Who actually keeps the world’s time-zone rules

It is natural to assume that something so fundamental is maintained by a large official body. It is not. The tz database is kept up to date by a small group of volunteers, coordinated for many years by a software engineer named Paul Eggert. They watch the world’s legislatures and decrees — a parliament abolishing daylight saving, an island changing which side of the date line it sits on, a territory adopting a new offset — and translate each change into an update to the data before it takes effect.

The project has not been without drama. In 2011 its stewardship moved to ICANN, the body that administers IANA, after a copyright lawsuit — the Astrolabe case — briefly disrupted the informal, mailing-list-based way the database had been maintained for decades. The suit was dropped, and the work carried on under a more stable home. The practical consequence for you is simple: when a government decides to change its clocks, that decision has to travel from the statute book, through these volunteers, into a tzdata release, and out to your device as a software update. Most of the time it arrives well ahead of the change and you notice nothing. When a country alters its rules at short notice — which happens more than it should — a phone that has not yet received the update will confidently show the wrong local time until it does. Almost every "my phone had the wrong time" story traces back to exactly that gap.