UTC, GMT and Time Zones Explained: How to Convert Time Across the World

London is five hours ahead of New York, except for the three weeks a year when it is four. How UTC, GMT and daylight saving really work.

Introduction

"London is five hours ahead of New York" is one of those facts everyone knows, and it is wrong for about three weeks of every year. For a stretch in March and again at the start of November, the gap is four hours, because the two regions change their clocks on different dates. Every year, meetings are missed on exactly those days.

Time zone conversion looks like simple addition, and it would be if offsets were fixed. They are not. This guide covers what UTC actually is, why it is not the same thing as GMT, how to convert between any two zones reliably, and the handful of traps that catch people who assume the arithmetic is stable.

UTC Is a Reference, Not a Time Zone

Coordinated Universal Time (UTC) is the standard the world sets its clocks against. It is maintained by a global ensemble of atomic clocks, and no country actually uses it as civil time. Its job is to be the fixed point that every local time is expressed relative to.

Greenwich Mean Time (GMT) is different in kind. It is a time zone, based originally on the position of the sun at the Greenwich meridian, and it is the civil time the United Kingdom keeps during winter. In summer the UK moves to British Summer Time, one hour ahead. So London is not "always GMT" - it is GMT for roughly five months of the year.

In everyday use the two labels are within a second of each other, since UTC is deliberately kept within 0.9 seconds of the Earth's actual rotation. The distinction matters because one is a measurement standard and the other is a place's local time, and only one of them changes twice a year.

How Offsets Work

Every zone is written as an offset from UTC. New York in winter is UTC-5; Berlin is UTC+1; Tokyo is UTC+9. To convert a local time to UTC you subtract the offset, and to go the other way you add it.

The geometry behind this is tidy: the Earth turns 360 degrees in 24 hours, so 15 degrees of longitude corresponds to one hour. That is the same planetary geometry that gives us the nautical mile, which our guide to nautical miles and statute miles explains in more detail.

The map, however, is political rather than geometric. China spans roughly five zones' worth of longitude and runs the entire country on UTC+8, so the sun rises in western Xinjiang around 10am by the clock. Zone boundaries bend around borders, and no formula derived from longitude will predict them.

The Offsets That Are Not Whole Hours

A surprising number of places sit on a half or quarter hour, which breaks any code or mental model that assumes integers:

The full range runs from UTC-12 to UTC+14, which means the world spans 26 hours, not 24. Two inhabited places can genuinely be on different calendar dates for most of the day.

Daylight Saving: Where the Arithmetic Breaks

Roughly a third of the world adjusts its clocks seasonally, and the ones that do rarely agree on when.

Those mismatched dates produce the windows the introduction mentioned. From the second Sunday in March until the last, the US has sprung forward while Europe has not, so New York sits at UTC-4 against London's UTC+0 and the gap narrows from five hours to four. The same thing happens in reverse for the week between Europe falling back in late October and the US doing so in early November.

Plenty of places skip the whole exercise. Most of Asia and Africa never adjust, Iran abolished the practice in 2022, and within the United States both Hawaii and most of Arizona stay on standard time all year while the rest of the country changes around them. In the southern hemisphere the seasons invert the effect: for part of the year Sydney is nine hours ahead of London, and for another part it is eleven.

The Reliable Method: Always Go Via UTC

Converting directly between two local times invites error, because you have to hold two variable offsets in your head at once. Converting through UTC turns one hard problem into two easy ones:

Take a 9:00am meeting in New York in January. New York is on Eastern Standard Time, UTC-5, so the time in UTC is 14:00. From there every other city falls out directly:

The word doing the work in both steps is current. An offset is a property of a place at a moment, not a permanent attribute, which is why any conversion needs a date attached as well as a time.

Writing Times So They Cannot Be Misread

Most scheduling failures are notation failures. Three habits remove nearly all of them.

Use the ISO 8601 format. Written as 2026-08-15T14:30:00Z, a timestamp is unambiguous everywhere: year first, 24-hour clock, and a trailing Z meaning UTC. The Z is why UTC is sometimes spoken as "Zulu time" in aviation and the military, where every operation is coordinated in UTC precisely to avoid this class of mistake.

Avoid zone abbreviations. They are not unique. CST is US Central Standard Time, China Standard Time and Cuba Standard Time - three zones spanning fourteen hours. IST covers India, Ireland and Israel. Write the offset, or a full zone name such as America/New_York, rather than initials.

Give a date with any offset. "3pm UTC+1" is only meaningful if the reader knows which side of a clock change it falls on.

Unix Timestamps and Leap Seconds

Software usually sidesteps the entire problem by counting seconds since 1 January 1970 at 00:00:00 UTC, the Unix epoch. A Unix timestamp has no zone and no daylight saving, so it can never be ambiguous. This is why the standard advice for databases is to store timestamps in UTC and convert to local time only when displaying them.

The one wrinkle is the leap second. Because the Earth's rotation is slightly irregular, 27 extra seconds have been inserted into UTC since 1972 to keep it aligned with astronomical time. They are unpredictable, announced only months ahead, and a persistent nuisance for systems that assume every minute has sixty seconds. In 2022 the international body responsible agreed to retire the practice by 2035, which will finally make UTC a continuous count.

Common Mistakes Worth Avoiding

Treating an offset as fixed

The gap between two cities is not a constant. Recurring calendar entries scheduled across a clock change are the single most common casualty.

Converting a date without the time

A deadline of "31 December" is 26 hours long globally. Attach a time and a zone, or expect submissions a full day apart to both claim they were on time.

Assuming a country has one zone

The United States has six, Australia has three, and Russia has eleven. "Time in the US" is not a well-formed question.

Storing local time in a database

During the autumn clock change, one local hour repeats. A timestamp recorded in local time within that hour is genuinely ambiguous, and no amount of later processing can recover which of the two it was.

Conclusion

Time zone conversion is only unreliable when you try to do it directly. Route every calculation through UTC, treat offsets as facts about a specific date rather than fixed properties of a city, and write timestamps in a notation that cannot be misread. The half-hour zones and the mismatched daylight saving dates stop being surprises and become details the method already handles.

Our world clock shows the current time across cities worldwide with the correct offset applied, including daylight saving wherever it is in force. If you need to work with durations rather than clock times, the hours to minutes converter handles the underlying units.

Related Articles