The clock stopped taking orders from the sun
Before 1972, civil time followed Greenwich Mean Time, which was tied to the Earth's rotation. The problem: the Earth is a lousy timekeeper. Its spin wobbles by fractions of a second a year, enough to matter once atomic clocks made nanosecond precision routine.
So a compromise got built.
UTC runs on International Atomic Time, a count of seconds ticked out by cesium clocks, and it corrects itself with leap seconds whenever the gap against the Earth's actual rotation gets close to a full second. That keeps UTC within 0.9 seconds of the old solar-based standard forever, without asking atomic clocks to slow down.
The name itself is a diplomatic dodge. English speakers wanted "CUT," French speakers wanted "TUC." Nobody agreed, so the International Telecommunication Union picked "UTC," which matches neither abbreviation and offends both languages equally.
Thirty-seven seconds is the current gap between TAI and UTC. Ten of those seconds were baked in when UTC launched in 1972, and twenty-seven more arrived one leap second at a time, most recently on December 31, 2016.
GMT is a zone name. UTC is the standard it borrows from.
People use "GMT" and "UTC" as if they mean the same thing, and for a calendar invite they do. For anything with a decimal point in the timestamp, they do not.
| Basis | UTC | GMT |
|---|---|---|
| Defined by | Atomic clocks (TAI) plus leap seconds | Earth's rotation, observed at Greenwich |
| Precision | Nanosecond-stable, corrected in whole seconds | Tied to solar noon, drifts with rotation |
| Legal status | The reference every time zone offsets from | A time zone name (Europe/London in winter) |
| Daylight saving | Never observed | Observed in the UK as BST in summer |
| City | Standard | DST | Note |
|---|---|---|---|
| Los Angeles | UTC-8 | UTC-7 | DST runs March to November |
| New York | UTC-5 | UTC-4 | Same DST window as Los Angeles |
| São Paulo | UTC-3 | UTC-3 | Brazil dropped DST in 2019 |
| London | UTC+0 | UTC+1 | GMT in winter, BST in summer |
| Karachi | UTC+5 | UTC+5 | Pakistan has not used DST since 2009 |
| Tokyo | UTC+9 | UTC+9 | Japan has run no DST since 1951 |
| Sydney | UTC+10 | UTC+11 | DST shifts the other way, October to April |
Notice São Paulo, Karachi, and Tokyo do not move between columns. Roughly two thirds of the world's population lives somewhere that has never run daylight saving, or dropped it years ago. UTC is the only column that behaves the same way everywhere. Convert against it with the Time Zone Converter instead of memorizing a table.
Where this catches people
Nobody sits down to learn UTC for fun. It shows up mid-task, usually while something else is already going wrong. Match the situation below to a tool instead of doing the math by hand.
Store UTC. Render local. Do not skip the middle step.
Every mainstream language gives you a UTC-aware clock. The mistake is not knowing that. The mistake is reaching for the naive, non-timezone-aware version because it's the one autocomplete suggests first.
Python
from datetime import datetime, timezone
now = datetime.now(timezone.utc)print(now.isoformat())# 2026-08-26T14:30:45.123456+00:00
# datetime.utcnow() still runs but is deprecated as of 3.12
# it returns a naive datetime with no timezone attached at allJavaScript
const nowUtc = new Date().toISOString();console.log(nowUtc);const d = new Date();console.log(d.getUTCHours(), d.getUTCMinutes());PHP
$utc = new DateTime('now', new DateTimeZone('UTC'));echo $utc->format('Y-m-d H:i:s');$local = new DateTime('2026-08-26 19:30:00', new DateTimeZone('Asia/Karachi'));$local->setTimezone(new DateTimeZone('UTC'));echo $local->format('Y-m-d H:i:s');One more wrinkle most guides skip: GPS time is not UTC. GPS started counting in January 1980 and has never applied a leap second since, so it now runs 18 seconds ahead of UTC. Your GPS chip converts that internally before handing you a normal clock reading, but if you are parsing raw GPS time in firmware, the 18-second gap is not a rounding error.
Reach for UTC, or reach for local time
Neither one wins outright. Pick based on who, or what, reads the timestamp next.
Reach for UTC
- Database columns and API payloads
- Server logs you will compare across regions
- Anything scheduled by a cron job or a queue
- Aviation, shipping, and satellite operations
Reach for local time
- Anything a person reads on screen
- Calendar invites, receipts, notifications
- "Today" and "this week" labels in a UI
- Anywhere the date, not just the hour, matters
One store-in-UTC habit avoids most of the daylight saving bugs a codebase will ever produce.
What this page will not do for you
An explainer is not a service. Here is where UTC stops helping.
- Fix a wrong system clock
- If your machine's clock has drifted, the fix is enabling NTP, not reading a definition. UTC is a standard, not a syncing mechanism.
- Tell you today's local date
- UTC can cross midnight while your local calendar date has not changed yet, or vice versa. Convert first if the date, not just the hour, is what matters.
- Rescue naive timestamp math
- Code that assumes every day has exactly 86,400 seconds can misbehave across a leap second. Large operators like Google and Amazon work around this by smearing the extra second across a full day instead of inserting it all at once. If your system does not do that, a leap second is a real edge case, not a theoretical one.
- Replace the IANA time zone database
- UTC tells you the offset. It does not track which regions changed their DST rules, when, or why. That history lives in the tz database your language ships with, and it gets patched several times a year.
Questions that come up after the table, not before it
- 01
Is UTC the same thing as GMT?
Close, not identical. GMT is a time zone name based on solar observation at Greenwich. UTC is an atomic time standard that stays within 0.9 seconds of GMT by inserting leap seconds. For a calendar invite the difference never matters. For a satellite orbit, it does.
- 02
Does UTC change for daylight saving time?
No. UTC holds one offset, permanently. London moves between UTC+0 and UTC+1 across the year. UTC itself does not move, which is the reason systems store timestamps in it instead of a local zone that shifts twice annually.
- 03
What does the Z at the end of a timestamp mean?
Z stands for Zulu, the military and aviation word for UTC. 2026-08-26T14:30:00Z and 2026-08-26T14:30:00+00:00 are the same instant written two ways. ISO 8601 accepts both.
- 04
Why does GPS time disagree with UTC by 18 seconds?
GPS time started counting in January 1980 and never applies leap seconds. UTC has inserted 18 leap seconds since that date, so GPS time now runs 18 seconds ahead. Your phone hides this by converting GPS time to UTC before it shows you a clock.
- 05
Are leap seconds going away?
The plan is yes. In November 2022 the General Conference on Weights and Measures voted to stop inserting leap seconds by 2035, favoring a larger allowed drift over the software outages leap seconds have caused at companies like Reddit and Cloudflare.
- 06
Should I store dates in UTC or in the user's local time zone?
Store the instant in UTC. Store the user's time zone name (for example Asia/Karachi) as a separate field if you need to render their local wall-clock time later. Storing a pre-converted local time throws away the information you need to convert it back correctly.
The rest of the clock
Timestamps rarely travel alone. Duration math, calendar work, and epoch conversion live next door in the full time toolset.
Store the instant in UTC. Show the person their own local wall clock. That order does not reverse.
