The Origins of Greenwich Mean Time (GMT)
Greenwich Mean Time has its roots in the 19th century, when the British Empire's maritime dominance required a reliable reference for navigation. In 1675, King Charles II founded the Royal Observatory in Greenwich, England, primarily to solve the "longitude problem" — how to determine a ship's east-west position at sea. For almost two centuries, Greenwich local mean solar time became the de facto standard for British sailors.
The watershed moment came in 1884 at the International Meridian Conference in Washington D.C. Representatives from 25 nations voted to make the Greenwich meridian (0° longitude) the Prime Meridian of the world. From that point forward, GMT became the international reference time — the time at the Prime Meridian from which all other time zones were measured as positive or negative offsets.
GMT is, at its core, an astronomical standard. It is based on the mean solar time at the Prime Meridian — that is, the average time it takes for the sun to travel from its highest point on one day to its highest point the next. This made perfect sense in an era when the sun was humanity's only reliable clock.
Why UTC Was Created
The 20th century brought a problem that astronomers had long suspected: Earth's rotation is not perfectly constant. The planet wobbles, its core churns, and seasonal changes in the atmosphere create tiny but measurable variations in the length of a day. For navigation and everyday life these variations are irrelevant, but for precision science, telecommunications, and the emerging field of computer systems, they were deeply problematic.
In the 1950s, physicists developed the atomic clock — a device that measures time by counting the vibrations of cesium-133 atoms. A cesium atom oscillates exactly 9,192,631,770 times per second, a figure so stable that an atomic clock loses or gains less than one second over 300 million years. This was the kind of precision that modern technology required.
Coordinated Universal Time (UTC) was formally established in 1960 and standardized in its current form by 1972. It is maintained by the Bureau International des Poids et Mesures (BIPM) in Paris, which averages the output of more than 400 atomic clocks in over 50 national laboratories around the world. The result is a timescale that is, for practical purposes, perfectly uniform.
The abbreviation "UTC" itself is a compromise. English speakers preferred "CUT" (Coordinated Universal Time) while French speakers preferred "TUC" (Temps Universel Coordonné). The International Telecommunication Union settled on "UTC" as a language-neutral acronym — one that does not perfectly abbreviate anything, which was precisely the point.
The Core Technical Difference
Here is the crux of the matter: GMT is based on the Earth's rotation; UTC is based on atomic clocks.
Because the Earth's rotation is irregular, GMT drifts slightly relative to the perfectly uniform atomic clock standard. UTC, however, is required by international agreement to never differ from GMT by more than 0.9 seconds. To enforce this constraint, the International Earth Rotation and Reference Systems Service (IERS) occasionally inserts a leap second — an extra second added to (or theoretically subtracted from) the UTC timescale to keep it synchronized with the Earth's actual rotational position.
Since 1972, 27 leap seconds have been added to UTC. They are always inserted at either June 30 or December 31 at 23:59:60 UTC — a time value that does not ordinarily exist. The most recent leap second was added on December 31, 2016. The IERS announced in 2022 that leap seconds will be abolished by 2035, after which UTC and astronomical time will be allowed to diverge by up to a full minute before any correction is applied.
Leap Seconds: A Genuine Headache for Software
Leap seconds are one of the most notorious sources of bugs in computing. The POSIX standard (which governs Unix-like operating systems) defines a day as exactly 86,400 seconds, meaning it has no concept of a 86,401-second day. When a leap second occurs, different systems handle it differently:
- Google's "leap smear": Google distributes the extra second over a 24-hour period, making each second in the day slightly longer than normal. This avoids the discontinuity but creates a period when Google's clocks differ from true UTC by up to 500 milliseconds.
- AWS time smear: Amazon uses a similar smearing approach over a shorter window.
- Hard insertion: Some systems simply insert the extra second, which can cause processes to see the clock jump backward or produce duplicate timestamps.
The 2012 leap second famously caused Cloudflare, Reddit, Qantas Airlines, and Mozilla all to experience outages simultaneously. This is a strong argument for always using UTC in software systems (where the irregularities are isolated to rare leap second events) rather than any local time format.
Why They Show the Same Time Most of the Time
For everyday purposes — telling the time, scheduling meetings, reading timestamps on emails — UTC and GMT are identical. Both are at offset +00:00. When you see "12:00 GMT" and "12:00 UTC" on the same day (outside of the rare seconds surrounding a leap second insertion), they refer to the exact same moment in time.
The UK itself observes GMT only in winter. During British Summer Time (BST), the UK is at UTC+1. So "GMT" in British parlance is both a time zone (UTC+0 in winter) and a historical standard — and this dual usage contributes to confusion.
Which Should Developers Use?
For software development, the answer is unambiguous: always use UTC. Here is why:
- UTC is a technical standard with a precise, atomic-clock-based definition. GMT is an astronomical standard with no governing authority enforcing precision.
- UTC is what operating systems, databases, and network protocols (NTP, PTP) actually use under the hood.
- Storing timestamps in UTC eliminates ambiguity during DST transitions, where local times can be repeated or skipped.
- UTC is the input expected by the ISO 8601 standard (the
Zsuffix stands for "Zulu time", which is UTC).
In JavaScript: new Date().toISOString() always returns UTC. In Python: datetime.utcnow() or the timezone-aware datetime.now(timezone.utc). In databases like PostgreSQL, store timestamps as TIMESTAMPTZ which always converts to UTC internally.
Practical Implications for Travelers and Businesses
For travelers, the distinction is largely academic. Flight schedules, hotel check-in times, and business hours are expressed in local time, with UTC offsets used only on technical itineraries. However, understanding that "UTC+0 in winter" and "GMT" mean the same thing when looking at a world clock helps avoid confusion when traveling to or scheduling calls with the UK.
For global businesses, the important point is that UTC never changes. Unlike the UK (which shifts to BST in summer) or the US (which observes DST), UTC is constant year-round. Scheduling a recurring meeting at "14:00 UTC every Tuesday" eliminates the twice-yearly confusion that comes with DST transitions.
In short: GMT is history; UTC is science. They show the same time today, but UTC is the living standard that your phone, your servers, and the Internet run on.
Frequently Asked Questions
Are UTC and GMT the same time?
For all practical purposes, yes. UTC and GMT both represent the time at the Prime Meridian with zero offset. The technical difference is that GMT is based on Earth's rotation while UTC is based on atomic clocks. They are kept within 0.9 seconds of each other through occasional leap second adjustments.
Why is the abbreviation UTC and not CUT?
The abbreviation UTC is a language-neutral compromise. English speakers preferred "CUT" (Coordinated Universal Time) and French speakers preferred "TUC" (Temps Universel Coordonne). The International Telecommunication Union chose "UTC" as an acronym that does not perfectly match either language.
Should I use UTC or GMT in my code?
Always use UTC in software development. UTC is the technical standard with a precise atomic-clock-based definition, and it is what operating systems, databases, and network protocols actually use. GMT is an astronomical standard with no modern governing authority enforcing precision.
What is a leap second?
A leap second is an extra second added to UTC to keep it within 0.9 seconds of Earth's rotational time. Since 1972, 27 leap seconds have been added, always at the end of June 30 or December 31. Leap seconds will be abolished by 2035 under a decision by the General Conference on Weights and Measures.
Do leap seconds cause software bugs?
Yes. Leap seconds are a notorious source of bugs because the POSIX standard defines a day as exactly 86,400 seconds. The 2012 leap second caused simultaneous outages at Cloudflare, Reddit, Qantas Airlines, and Mozilla. Modern cloud providers like Google and AWS use "leap smearing" to distribute the extra second gradually.
Does the UK use GMT or UTC?
The UK uses GMT (UTC+0) during winter months and British Summer Time (BST, UTC+1) during summer. "GMT" in British usage refers both to the historical time standard and to the UK's winter time zone. Technically, the UK's legal time standard is UTC, but GMT remains the common term.
What is the Z in timestamps like 2026-03-13T15:30:00Z?
The "Z" stands for "Zulu time," the NATO phonetic alphabet designation for the letter Z, which represents UTC (zero offset). In ISO 8601 timestamps, appending Z indicates that the time is in Coordinated Universal Time with no local offset applied.
Sources
- BIPM: Bureau International des Poids et Mesures — International Atomic Time (TAI)
- IERS: International Earth Rotation and Reference Systems Service — Bulletin C (Leap Second Announcements)
- ITU-R TF.460: Standard-frequency and time-signal emissions
- NIST: National Institute of Standards and Technology — A Brief History of UTC