At 9:00 in London, it may be 10:00 in Paris, 13:30 in Delhi, 18:00 in Sydney, and 04:00 in New York. That is the familiar time zone puzzle. Beneath it sits a quieter question: what clock are all those places being compared against?
For a long time, the answer was Greenwich Mean Time, or GMT. It came from astronomy, navigation, and the practical need for sailors and railways to agree on time. Today, the technical answer is usually Coordinated Universal Time, or UTC. It comes from atomic clocks, international coordination, and the need for computers, satellites, aviation, science, finance, and communications to agree on a stable reference.
In daily speech, UTC and GMT often point to the same clock reading. In January, 12:00 UTC and 12:00 GMT are usually the same civil time in the United Kingdom. But the terms are not identical. GMT is historically tied to mean solar time at Greenwich and is also used as a civil time zone name. UTC is the international time standard used for precision coordination.
The difference is not trivia. It prevents missed meetings, broken logs, bad timestamps, confused flight schedules, and software bugs that appear twice a year when daylight saving changes. And as of 2026 the definition of UTC itself is up for a vote, which is covered further down.
Greenwich First Became the Reference Point
Before global standard time, local noon meant the moment the sun reached its highest point in a particular place. That worked when people moved slowly. It became awkward when railways, telegraphs, shipping schedules, and international commerce required coordination across distance.
Greenwich became important because Britain was a major naval and trading power, and the Royal Observatory at Greenwich was already central to nautical navigation. Longitude at sea depended on knowing the time difference between local noon and a reference clock. Accurate clocks helped sailors know how far east or west they were.
In October 1884, the International Meridian Conference in Washington selected the meridian through the Greenwich transit instrument as the prime meridian for longitude, and recommended a universal day counted from mean midnight at Greenwich. That did not instantly make every clock in the world use GMT, but it made Greenwich the central reference for maps, navigation, and timekeeping.
There is a nice modern footnote here. The prime meridian used by GPS and every other satellite system, the IERS Reference Meridian, sits about 102 metres east of the brass line in the Observatory courtyard that tourists queue to stand on. Nothing moved. Modern reference frames are tied to the Earth's centre of mass rather than to a local vertical, and the historic line was defined by a telescope pointed along a plumb line that local gravity pulls very slightly off true. Stand on the tourist line with a phone and it will show a longitude near 0.0015 degrees west.
GMT was based on mean solar time at Greenwich. "Mean" matters because apparent solar days vary through the year due to Earth's orbit and axial tilt. Mean solar time smooths those variations into a more regular clock.
For everyday life, GMT was good enough. For modern technology, "good enough" became too loose.
Why "GMT" Is Ambiguous Even to Astronomers
There is a second reason technical work avoids the term, and it has nothing to do with British Summer Time.
Astronomers originally reckoned the Greenwich day from noon, not midnight, so that a single night's observations fell on one date. Civil users reckoned it from midnight. The same label therefore meant two clocks 12 hours apart depending on who was speaking. The astronomical convention was changed to a midnight start on 1 January 1925, and the name Universal Time was introduced afterwards precisely to escape the ambiguity that "GMT" had accumulated.
That is why modern precision work uses UT1 for the Earth-rotation timescale and UTC for the coordinated one, and leaves GMT to civil and casual use. When the article you are reading says GMT and UTC are "not the same concept," this is the concrete reason: GMT is a name with historical baggage, while UT1 and UTC are defined quantities.
Solar Time Is Elegant, But Earth Is Not a Perfect Clock
Solar time is intuitive. Noon is roughly when the sun is highest. Days come from Earth's rotation. Years come from Earth's orbit. Human timekeeping grew from the sky.
The problem is that Earth is not a perfectly steady timekeeper. Its rotation varies due to tidal friction, the movement of mass inside the planet, atmosphere and ocean dynamics, and the redistribution of water and ice at the surface. The changes are tiny, but global systems care about tiny errors when clocks coordinate satellites, radio signals, databases, telescopes, and high-speed trading systems.
Atomic clocks changed the standard. They measure time using the regular frequency of atomic transitions, which is far more stable than Earth's rotation. That precision created a new tension: civil time still needs to stay roughly aligned with the sun, but technical time needs a stable second.
UTC is the compromise.
What UTC Actually Is
UTC stands for Coordinated Universal Time. The abbreviation looks odd because English and French naming conventions were reconciled into one neutral abbreviation. English would suggest CUT. French would suggest TUC. UTC became the shared compromise.
UTC runs at the rate of International Atomic Time (TAI) and is offset from it by a whole number of seconds. Leap seconds are inserted occasionally so that UTC never drifts more than 0.9 seconds away from UT1, the timescale defined by the Earth's actual rotation. That is the design in one sentence: atomic rate, solar alignment, integer-second corrections.
The current offset is 37 seconds. That is 10 seconds from the initial 1972 alignment plus the 27 leap seconds inserted since.
Most people do not need to think about leap seconds day to day. But the existence of UTC explains why modern systems prefer it. UTC is not a local time zone with summer rules. It is a reference standard. Local times are usually expressed as offsets from UTC.
New York during Eastern Standard Time is UTC-5. During Eastern Daylight Time, it is UTC-4. Paris is UTC+1 in winter and UTC+2 during summer time. India is UTC+5:30 all year. Nepal is UTC+5:45. Kiribati's Line Islands run UTC+14, and Baker Island is UTC-12, so the inhabited world spans 26 hours of clock time and there are always two different calendar dates in progress somewhere. Time zones are political and regional. UTC is the anchor.
When you need to compare places, use the Time Zone Converter. It handles offsets and daylight saving rules that are easy to misremember.
The Leap Second Is Being Retired
This is the part of UTC that has changed most since the standard was written, and any guide that describes leap seconds as routine ongoing practice is now out of date.
The facts as of September 2026:
- No leap second has been inserted since 31 December 2016. Twenty-seven have been added in total since 1972, but the Earth stopped cooperating with the trend. Since roughly 2015 the planet has been rotating slightly faster, not slower.
- In November 2022 the 27th General Conference on Weights and Measures (CGPM) passed Resolution 4, deciding that the maximum permitted difference between UT1 and UTC will be increased in or before 2035, and asking the International Committee for Weights and Measures to bring a concrete proposal to the following conference. In effect, that was the decision to stop inserting leap seconds.
- That conference is happening now. The 28th CGPM meets from 13 to 15 October 2026 at Versailles, and will vote on the implementing resolution. Reporting ahead of the meeting indicates delegates are weighing an immediate end to leap seconds rather than waiting for 2035, and a replacement mechanism based on a "leap hour": let UTC and UT1 drift until they differ by 3,600 seconds, which would not happen for centuries.
- The reason for the hurry is the negative leap second. Because Earth has sped up, the next correction might have to remove a second rather than add one, something that has never been done. Estimates put the probability of a negative leap second being needed by 2035 at around 30%. Almost no production software has ever executed one, and a great deal of it assumes seconds only ever repeat, never vanish.
If you are reading this after mid-October 2026, check the CGPM resolutions page for what was actually adopted. Nothing above changes how you write a timestamp today, but it changes what "UTC" will mean over the coming decades: a timescale that no longer tracks the sunrise.
GMT in Everyday Use
GMT still matters. It appears in UK civil time, weather reports, historical documents, watches, broadcasting, and ordinary conversation. During winter, the United Kingdom uses GMT as civil time. During summer, it uses British Summer Time, which is UTC+1.
That creates one common mistake: people say "GMT" when they really mean "UK local time." In July, 9:00 in London is not 9:00 GMT. It is 9:00 BST, which equals 08:00 UTC.
If someone schedules a call for "9 AM GMT" in summer, there are two possibilities. They may literally mean 9 AM at UTC+0, or they may casually mean 9 AM London time. Those are not the same. Good scheduling language avoids this ambiguity by saying "9 AM London time" or "08:00 UTC."
GMT can be a historical standard, a winter civil time, or a loose shorthand. UTC is cleaner for technical coordination.
Why Aviation, Weather, and Computing Prefer UTC
Aviation uses UTC because aircraft cross borders quickly and flight plans cannot rely on local clock rules at every point along a route. Pilots and air traffic controllers need one reference. Weather observations also use UTC so data from different stations can be compared correctly.
Computing uses UTC for a similar reason. Servers may run in different countries. Users may travel. Databases may store events from many regions. Logs may need to reconstruct a chain of events after an outage. If every machine stores local time, daylight saving and time zone changes turn analysis into a mess.
The usual software pattern is:
- Store timestamps in UTC.
- Convert to local time only for display.
- Keep the user's time zone separate from the instant in time.
This is why an event in a database may be stored as 2026-09-09T14:30:00Z. The Z is defined by ISO 8601 and by RFC 3339 as a zero UTC offset, and is read aloud as "Zulu" in aviation and military use.
One RFC 3339 subtlety is worth knowing: Z and +00:00 mean the same instant, but the standard reserves -00:00 to mean "this is UTC and the local offset is unknown." If you are generating timestamps, write Z.
The Timestamp Converter is useful when you need to turn a Unix timestamp into a readable UTC or local time. That matters because computers often store time as numbers rather than human calendar strings.
Unix Timestamps: Counting Seconds From a Fixed Point, With One Catch
A Unix timestamp counts seconds from 00:00:00 UTC on 1 January 1970, stripped of human calendar language. A timestamp does not inherently say "London" or "Tokyo." It represents an instant.
That design is powerful. It lets systems compare events without first asking which country the user is in. But it can confuse people because the same instant displays differently around the world.
Suppose a timestamp represents 18:00 UTC. In London during winter, that displays as 18:00. In New York during standard time, it displays as 13:00. In Tokyo, it displays as 03:00 the next day. The instant is the same. The local representation changes.
Here is the catch that trips up people who assume the number is a physical stopwatch. Unix time is not a count of elapsed seconds. POSIX defines seconds-since-the-epoch by a fixed formula built from the calendar date and time, with 86,400 seconds in every day. Leap seconds have no place in that formula, so they are simply not counted.
The practical consequences:
- Between 1 January 1970 and today, the true elapsed physical time is 27 seconds longer than the difference between two Unix timestamps suggests.
- During a positive leap second, the same Unix timestamp value covers two distinct seconds of real time. Systems have handled this by repeating a value, or by "smearing" the extra second across many hours so no clock ever steps backwards.
- Unix time is therefore excellent for calendars, scheduling, and ordering events at ordinary resolution, and the wrong tool for measuring precise physical intervals. For that, use a monotonic clock, or TAI.
This is the central time zone lesson in its sharpest form: a timestamp, a wall-clock time, and a physical duration are three different kinds of object.
Daylight Saving Is a Rule Layer, Not a UTC Change
UTC does not observe daylight saving time. Local places do.
That distinction prevents many mistakes. A city may shift its offset from UTC when daylight saving begins or ends. UTC itself does not jump forward or backward. It keeps ticking.
Daylight saving rules vary by country, region, and year, and they are changed by legislatures at short notice. Some places do not use it. Some used it in the past and stopped. Some change the date rules. Treating time zones as fixed numbers is dangerous for future dates.
For example, "New York is UTC-5" is only true part of the year. In summer, New York is usually UTC-4. "London is UTC+0" is true in winter, but not during British Summer Time.
This is why the practical rule for software is: store a zone identifier, not an offset, for anything in the future. A meeting saved as Europe/London will still be correct if the rules change before the meeting happens. The same meeting saved as UTC+1 will silently be wrong.
Those identifiers come from the IANA Time Zone Database, the shared dataset that operating systems, browsers, and programming languages all read. It is revised whenever a government changes its rules; release 2026c came out on 8 July 2026. If your servers have not taken a tzdata update in a year, some of your future dates are already wrong.
For planning calls or deadlines, convert the actual date and time, not just the city. A conversion for January may not match July.
The Difference Between Duration and Clock Time
A meeting that lasts two hours is a duration. A flight departing at 22:30 local time is a clock time. A server event at a Unix timestamp is an instant. Mixing those categories creates errors.
The Time Converter helps with durations such as seconds, minutes, hours, days, and weeks. It does not answer the same question as a time zone conversion. Converting 36 hours into 1.5 days is not the same as asking what 09:00 London time is in Singapore.
Professionals keep these ideas separate:
- Duration: how long something lasts.
- Local time: what a wall clock shows in a place.
- UTC instant: a global reference point.
- Time zone: the rule that maps an instant to local clock time.
Once you separate those layers, time problems become less mysterious.
A Practical Scheduling Example
Imagine a team with people in London, Toronto, Berlin, and Singapore. Someone writes: "Deploy at 10 PM GMT."
In January, that might mean 22:00 UTC. London is on GMT, Berlin is UTC+1, Toronto is UTC-5, Singapore is UTC+8.
In July, the same wording is risky. If the writer means 10 PM London time, that is 21:00 UTC because London is on BST. If they literally mean 22:00 GMT, London clocks show 23:00.
The safer message is:
"Deploy at 21:00 UTC on 14 July. Local display: 22:00 London, 23:00 Berlin, 17:00 Toronto, 05:00 Singapore on 15 July."
Check that arithmetic once, because it is the whole point of the example. London on BST is UTC+1, so 21:00 UTC is 22:00. Berlin on CEST is UTC+2, so 23:00. Toronto on EDT is UTC-4, so 17:00. Singapore is UTC+8 all year, so 05:00 the next morning. Note that three of those four offsets are the summer values, and only Singapore's would be the same in January.
That sentence is longer. It is also less likely to break production.
When GMT and UTC Can Be Treated the Same
For many everyday uses, GMT and UTC have the same clock reading. If a casual weather page says GMT and a technical page says UTC, the displayed hour will match. That is why people often use the terms interchangeably.
Still, the habit can backfire in three situations:
- Summer time in the UK or other daylight saving regions.
- Technical systems that require precise standard naming.
- Historical or astronomical work, where GMT before 1925 may be counted from noon, and where UT1 and UTC differ by a fraction of a second that some measurements care about.
Use GMT when you specifically mean Greenwich Mean Time or UK winter civil time. Use UTC when you mean the global technical reference.
FAQ
Is UTC the same as GMT?
They usually show the same clock time, but they are not the same concept. GMT comes from mean solar time at Greenwich and carries historical ambiguity, including a noon-based day before 1925. UTC is the modern international standard: atomic in rate, kept close to the Earth's rotation by whole-second corrections.
Does UTC have daylight saving time?
No. UTC does not change for daylight saving. Local time zones may change their offset from UTC during the year.
Are leap seconds going away?
Effectively yes. The CGPM decided in 2022 that the tolerance between UT1 and UTC will be widened in or before 2035, and the 28th CGPM meeting on 13 to 15 October 2026 votes on how and when. None has been inserted since 31 December 2016, and the current TAI minus UTC offset is 37 seconds.
Why do computers store time in UTC?
UTC gives systems a stable reference that does not depend on local time zone rules. Local time can be applied later for display. For future-dated events, store an IANA zone identifier such as Europe/London alongside it, because offsets change when governments change the rules.
Do Unix timestamps count leap seconds?
No, and this surprises people. POSIX defines the value from the calendar date with exactly 86,400 seconds per day, so leap seconds are skipped. The gap between two Unix timestamps is therefore not a precise measurement of elapsed physical time. Use a monotonic clock for that.
What does the Z mean in a timestamp?
Z denotes a zero UTC offset in ISO 8601 and RFC 3339, and is spoken as "Zulu." It appears in timestamps such as 2026-09-09T14:30:00Z.
Why is GMT still used?
GMT remains common in civil language, broadcasting, watches, historical contexts, and UK winter time. It is familiar, but UTC is preferred for technical precision.
What is the safest way to schedule internationally?
Quote a UTC time with the full date, and name the cities with their local times as a cross-check. For critical events, verify with the Time Zone Converter, especially near daylight saving transitions.
Sources
- Resolution 4 of the 27th CGPM (2022) - International Bureau of Weights and Measures. Source for the decision to increase the maximum UT1 minus UTC difference in or before 2035 and to bring an implementation proposal to the next conference.
- 28th meeting of the CGPM (2026) - BIPM. Source for the 13 to 15 October 2026 dates and the Versailles venue.
- The leap second is dead. Long live the leap hour? - Nature news, 2026. Source for the October 2026 vote, the leap hour proposal at a 3,600-second difference, the roughly 30% probability of a negative leap second being needed by 2035, and the count of 27 leap seconds added since the 1970s.
- Leap seconds and Future of leap seconds - timeanddate.com. Source for the 31 December 2016 date of the most recent leap second.
- Time Zone Database - IANA. Source for the tzdb 2026c release on 8 July 2026 and for the zone-identifier guidance.
- Why the Greenwich meridian moved - Malys and colleagues, Journal of Geodesy 89, 2015. Source for the roughly 102 metre offset between the historic Airy transit line and the IERS Reference Meridian, and its explanation.
Standards and dates were checked in September 2026. Leap second policy is under active decision this autumn, so verify the CGPM outcome before quoting the 2035 timetable. All scheduling examples are BlinkCalc illustrations.
Scheduling Without Surprises
GMT and UTC usually show the same hour, but they answer different questions: GMT is mean solar time at Greenwich and a UK civil time zone, while UTC is the stable atomic reference that aviation, computing, and science coordinate around. That reference is about to become steadier still, as the leap second is retired and UTC stops chasing the Earth's rotation second by second. When a schedule matters, name a city or quote a UTC time with the date attached, store a zone identifier rather than an offset for anything in the future, and treat daylight saving as a local rule layered on top of an unchanging UTC clock. For more on the offsets behind everyday scheduling, see Time Zones and Time Differences Explained, and to decode the numbers computers store, Unix Timestamp Converter Explained With Examples.