Quick — what's the difference between UTC and GMT?

If you said "nothing," you're not alone. A lot of developers use them interchangeably. And for most practical purposes, they are the same. But technically, they're not. And if you're building software that handles time — which, let's face it, is most software — understanding the difference matters.

⏱️ The Short Answer

GMT (Greenwich Mean Time) is a time zone. It's the time at the Royal Observatory in Greenwich, London, based on the mean solar time.

UTC (Coordinated Universal Time) is a time standard. It's based on International Atomic Time (TAI) with leap seconds added to keep it within 0.9 seconds of astronomical time.

In everyday usage, they're the same. The current time in GMT and UTC is identical. But under the hood, they're defined differently — and those differences matter in specific contexts.

📜 A Brief History

GMT was established in 1847 by the British railways, and it became the world's first standardized time reference. In 1884, the International Meridian Conference designated Greenwich as the Prime Meridian, making GMT the global reference point for time zones.

But GMT has a problem: it's based on the mean solar time at Greenwich, which is affected by the Earth's irregular rotation. The Earth doesn't spin at a perfectly constant rate — it slows down slightly over time and fluctuates due to geological and atmospheric factors.

For most of history, this didn't matter. But in the mid-20th century, as atomic clocks became more precise, scientists needed a time standard that was stable and wouldn't drift. That's where UTC comes in.

UTC was formally adopted in 1960 (as "Coordinated Universal Time") and has been the global standard ever since. It's based on International Atomic Time (TAI) — a weighted average of hundreds of atomic clocks around the world — with leap seconds added occasionally to keep it close to astronomical time.

🔬 The Technical Differences

Here's a breakdown of the key differences:

• Definition: GMT is a time zone; UTC is a time standard.
• Basis: GMT is based on solar time; UTC is based on atomic time.
• Leap seconds: UTC includes leap seconds; GMT does not (in the technical sense).
• Precision: UTC is more precise. Atomic clocks are accurate to nanoseconds; solar time is accurate to milliseconds at best.
• Usage: UTC is used in science, aviation, computing, and international timekeeping. GMT is used in the UK, parts of Africa, and as a colloquial term for UTC.

The practical difference is tiny — usually less than a second. But for systems that need extreme precision (like GPS, financial trading, or scientific instruments), the distinction matters.

🌐 Why the Confusion Exists

Part of the confusion comes from the fact that GMT and UTC share the same offset (UTC+0). If you're in London in winter, GMT and UTC are the same. If you're in London in summer, GMT is still UTC+0, but the UK switches to British Summer Time (BST), which is UTC+1.

Another source of confusion: many programming languages and libraries use "GMT" and "UTC" interchangeably. For example, JavaScript's Date object has getUTCHours() and getGMTHours() — and they return the same thing. This is convenient, but it reinforces the idea that they're identical.

They're not. They're just very close.

💻 Practical Implications for Developers

Here are some concrete things to keep in mind:

1. Always store timestamps in UTC

This is the golden rule. Store everything in UTC, and convert to local time at the display layer. If you store local time, you'll have to deal with time zone conversions every time you query your database — and you'll inevitably get it wrong.

2. Use a proper time zone library

Don't try to handle time zones manually. Use a library like Luxon, date-fns-tz, or Moment Timezone (for JavaScript), or pytz / zoneinfo for Python. These libraries have the full time zone database and handle edge cases correctly.

3. Be careful with leap seconds

Most programming languages don't handle leap seconds well. Unix time, for example, doesn't include leap seconds — it treats every day as exactly 86,400 seconds. This means that Unix time drifts from UTC by a few seconds over decades. For most applications, this doesn't matter. For high-precision systems, it does.

4. Don't assume "UTC" and "GMT" are always the same

In 99.9% of cases, they are. But if you're working with historical data, scientific instruments, or systems that need sub-second precision, the difference matters. Be explicit about which one you're using.

5. Understand the difference between offset and time zone

A time zone is a geographic region with a specific offset and rules for daylight saving. An offset is just a number (like +05:30). Two different time zones can have the same offset at a given moment but different rules for DST. Don't confuse them.

🧪 A Concrete Example

Let's say you're building a scheduling app. A user in New York creates a meeting for "3 PM on March 15, 2026."

If you store that as a local time string ("2026-03-15T15:00:00"), you've lost the time zone information. When another user in London views it, you don't know whether to show it as 8 PM or 7 PM — because you don't know if the original time was in EST or EDT.

If you store it as UTC ("2026-03-15T19:00:00Z"), you've preserved the exact moment in time. Now you can convert it to any time zone correctly.

The rule is simple: store moments, not wall-clock times. A moment is a specific instant in time (UTC). A wall-clock time is what a clock on the wall says in a particular place. They're different, and confusing them is one of the most common sources of bugs in time-handling code.

✅ The Bottom Line

UTC and GMT are functionally the same for almost all purposes. But technically, they're different: UTC is an atomic time standard, and GMT is a solar-based time zone. Use UTC in your code, store everything in UTC, and convert to local time only when displaying to users.

And if someone asks you the difference at a party, you'll be the person who actually knows.

Working with time zones in your code? Our Time Zone Converter Hub uses the full IANA time zone database — the same one your code should be using.