UTC Offsets and Daylight Saving Time: A Practical Guide

"UTC+8" looks like a fixed property of a place, the way latitude is. It is not. It is a rule — and in many countries the rule changes twice a year. Almost every timezone mistake in scheduling, logging, or software comes from treating a rule as a fact.

This guide covers what an offset actually means, how to read the unusual ones, which places still change their clocks, and the specific failures that happen on transition days.

Map: CIA — public domain, via Wikimedia Commons

What an offset is

An offset is the difference between a local clock and Coordinated Universal Time, written as UTC followed by a sign and a number of hours.

• UTC+08:00 means the local clock reads 8 hours ahead of UTC. When it is 04:00 UTC, it is 12:00 locally.
• UTC−05:00 means the local clock reads 5 hours behind UTC. When it is 04:00 UTC, it is 23:00 the previous day locally.

The sign is the part people get wrong most often. A positive offset is east of the prime meridian, a negative offset is west. East is ahead, west is behind.

GMT and UTC are not quite the same thing

GMT (Greenwich Mean Time) is a time zone with offset UTC+0, still used in the UK in winter. UTC is the atomic time standard that offsets are measured against. In everyday use they are interchangeable, but "GMT+8" is technically sloppy — the correct form is "UTC+8". Some systems still emit GMT-style labels; treat them as UTC.

Offsets that are not whole hours

Roughly three-quarters of the world's offsets are whole hours, which makes the rest easy to forget:

Nepal's 45-minute offset is the only one of its kind in the world. If you are building anything that assumes offsets are multiples of 3600 seconds, these rows are the ones that break it.

One country, one offset

China spans about five geographic hours but uses a single offset, UTC+8, across the whole country. In western Xinjiang the sun can rise around 10:00 local time. Spain sits geographically at roughly UTC+0 but uses UTC+1 (and UTC+2 in summer) to align with central Europe. These are political choices, not astronomical ones — a useful reminder that a time zone is legislation, not geometry.

Daylight saving time

DST moves the clock forward by an hour in spring and back in autumn, so that daylight hours line up better with working hours.

Who changes their clocks

• European Union and UK — last Sunday of March to last Sunday of October.
• United States and Canada — second Sunday of March to first Sunday of November.
• Australia and New Zealand — southern hemisphere, so the dates are reversed: DST starts in late September or early October and ends in early April.
• Chile, Paraguay, parts of Brazil — southern hemisphere schedules with local variations.

Who does not

• China — DST was tried from 1986 to 1991 and abandoned.
• Japan — DST was in force from 1948 to 1951 and has not returned.
• India, most of Southeast Asia, Russia, Turkey — no DST.
• Most of Africa and the Middle East — no DST, with exceptions.
• Hawaii, Arizona (except the Navajo Nation), Puerto Rico — US jurisdictions that opt out.

If you are coordinating between Tokyo and New York, the gap is 14 hours for most of the year, then briefly 13, then 14 again. The number is not stable; only the two zones' rules are.

The transition-day failures

Two specific bugs recur every year, and both come from assuming that every local time exists exactly once.

Spring forward: a local time that never happens. In the US, clocks jump from 02:00 to 03:00. There is no 02:30 that day. A scheduled job set for 02:30 either does not run, runs at 03:00, or runs twice, depending on the system. The same applies to the EU's 01:00 to 02:00 jump — 01:30 does not exist.

Fall back: a local time that happens twice. Clocks go from 02:00 back to 01:00, so 01:30 occurs twice, an hour apart. A naive scheduler will fire twice. A log line stamped "01:30" is ambiguous without an offset.

The robust fix is the same in both cases: store and compare times in UTC, convert to local only for display. UTC has no DST and never repeats or skips a second. A database column holding local time without an offset is a bug waiting for March.

A practical checklist

1. Never store a local time without its offset. 2026-03-08 02:30 is not a moment in time; 2026-03-08T02:30-05:00 is.
2. Prefer IANA zone names over offsets in configuration. America/New_York knows its own DST rules; UTC-5 does not.
3. Check the transition dates for both sides before scheduling a recurring meeting. One side may shift while the other does not.
4. Expect the gap. If a recurring job is scheduled between midnight and 03:00 local, verify what happens on transition days.
5. Do not assume whole hours. Half-hour and 45-minute offsets are real and will break naive arithmetic.

Checking a conversion

For a one-off conversion, the fastest reliable method is to look at both zones side by side rather than do arithmetic. The timezone converter shows the current offset for each zone and accounts for DST automatically; the world clock is better for watching several zones at once.

For durations rather than points in time — "how many hours between these two timestamps" — use the time calculator, which works in absolute elapsed time and is therefore immune to DST entirely.