How a Phone Knows What Time It Is, and What an Alarm Does With It
A phone gets its time from NTP servers, carrier NITZ messages and GPS, then stores your alarm as a local wall-clock time that tzdata rules translate.
In this article9 sections
R.: How does my phone know it’s 6:30 when it wakes me up?
M.: It takes the time from a network source (an NTP server, the carrier’s NITZ message, or GPS), counts seconds on a quartz crystal between corrections, and fires the alarm when that clock reaches a wall-clock time computed from the time zone database.
This is a constructed conversation between two engineers, M. and R.; neither is a real person, and the facts were checked against the sources linked in the text. It extends the clock-synchronization analogy used for body clocks to phone hardware.
Where does the phone get its time in the first place?
M.: Three places. The carrier sends NITZ, Network Identity and Time Zone, a GSM Phase 2+ feature that lets the network hand the handset universal time, local time zone and a daylight saving offset. All optional fields, defined in 3GPP TS 22.042. The phone also asks an NTP server. And a GPS fix carries time too.
R.: Which one wins?
M.: Depends on the OS. Android’s documentation says that from Android 12 the framework prefers NTP over NITZ because NTP is more accurate and reliable, and that Android 11 and earlier did the reverse. The default server is time.android.com, which uses SNTP, the simplified variant. For Apple, time.apple.com is named on community forums, not in Apple documentation, so treat it as probably true and unconfirmed.
R.: And the protocol?
M.: NTP version 4 is RFC 5905 (Mills et al., IETF, 2010). The client stamps a request, the server stamps its receipt and reply, and the four timestamps give both round-trip delay and the client’s offset. A phone on a decent connection lands within tens of milliseconds. Nobody’s alarm cares about that.
Why does GPS time disagree with UTC?
R.: GPS says it is time, the satellite is very confident, and it’s off.
M.: Different scale, not wrong. GPS time started on 6 January 1980, matched to UTC, and never adds leap seconds. It is now 18 seconds ahead of UTC, and has been since 1 January 2017. The satellites broadcast the offset so the receiver can correct it. Since almost every phone otherwise pretends a day has 86,400 seconds, the 6:30 alarm has no idea a leap second ever existed.
How far does a phone clock drift between syncs?
R.: What if the sync never comes? Plane, basement, dead zone.
M.: Then it runs on the crystal. A typical 32.768 kHz watch crystal (the electronic descendant of the balance wheel and mainspring in a wind-up alarm) is specified around plus or minus 20 ppm at room temperature. 20 ppm is 20 microseconds of error per second, and a day has 24 x 60 x 60 = 86,400 seconds. 86,400 x 0.000020 = 1.728 seconds per day. Over a week that is 12.1 seconds, over 30 days about 52.
R.: That’s the room-temperature spec. The curve on those crystals is a parabola, so a phone in a hot car does worse.
M.: I would not put a number on the hot car. And real handsets can be corrected against the cellular network, so treat 1.7 s a day as a rough bound for a device that never syncs.
What does an alarm do with a synced clock?
R.: You set an alarm for 6:30. What is stored?
M.: A local time of day and the current time zone. Wall-clock intent, not a fixed instant. When the alarm is armed, the OS converts 6:30 tomorrow in your zone into an absolute instant using the time zone database (tzdata, the IANA database), then schedules for that instant.
R.: So the interesting failure is when the rules change under it.
M.: Right. Mexico passed its law abolishing most daylight saving time in the last week of October 2022, effective 30 October. The tz maintainers shipped 2022f on 29 October (UTC), about a day before. A phone still carrying older rules would compute the wrong instant for a 6:30 alarm and be an hour off. Nothing drifted. The data was stale. A change that is already in the rules is the easy case: for the clock changes of 2026-27 you can work out which minutes vanish or repeat in each zone ahead of time.
R.: And if you cross time zones with the alarm armed?
M.: It should re-resolve when the zone changes, but I do not know how each OS treats an alarm already scheduled at that moment, or which alarm type the stock clock app uses on Android. I would test it before trusting it. The early-flight checklist exists partly because that test is expensive on the wrong morning.
R.: A one-second error is invisible to a sleeper. An hour is not.
M.: The sync is fine. The rule data surprises people, and what changed and when is listed in the tz database release notes.
Two-minute footnotes
How does a time zone rule change reach a phone?
On Android 10 and later the time zone data ships as an updatable module (an APEX file), so the fix can arrive without a full OS upgrade: the device downloads it, reboots, then applies it. Android’s documentation says the older APK-based mechanism was deprecated in Android 10. A phone that never installs the update keeps computing with the old rules.
Will leap seconds stop being added?
The 27th General Conference on Weights and Measures (2022, Resolution 4) decided that the allowed UT1-UTC difference will be enlarged in or before 2035, which ends leap seconds as currently practiced. The last one was added on 31 December 2016, and 27 have been added since 1972. IERS Bulletin C 71 (January 2026) covers June 2026 only, announcing no leap second then. The replacement limit had not been chosen when the resolution passed.
What is the difference between a wall-clock alarm and an elapsed-time alarm?
Android’s alarm documentation names two clock types. RTC alarms use wall-clock time (System.currentTimeMillis) and suit alarms tied to the current locale. Elapsed-real-time alarms count from boot, are unaffected by time zone or locale, and are what the documentation recommends whenever you can use them. A 6:30 alarm is inherently the first kind, because the hour means something only in a zone.
Does airplane mode stop the clock from being correct?
No. The clock keeps counting on the local oscillator whether or not a radio is on. It just goes without corrections, so it drifts by whatever the crystal drifts, on the order of a couple of seconds a day at 20 ppm.