The reference desk for online sellers
Codes & Standards

Time Zones for Campaign Scheduling: UTC Offset Reference

Standard UTC offsets from UTC-12 to UTC+14 with example cities, plus which markets move their clocks for daylight saving and which stay fixed.

Reference · July 31, 2026 · 4 min read

Three plain white analog wall clocks showing different positions on a slate grey wall
Photo: Dave Catchpole (BY) via Openverse

A campaign scheduled in your own time lands at the wrong hour for half the world. This page lists standard UTC offsets with example cities, then flags the markets that shift for daylight saving so your sends stay on time all year.

Data checked: July 26, 2026. Offsets shown are standard time (Northern winter). Read the daylight saving section before you schedule.

Read this first: offsets move

The offsets in the table are standard time. Where daylight saving is observed, the clock moves forward one hour in that region’s summer, so the offset changes for part of the year. Northern and Southern hemisphere summers fall in opposite months, so their clock changes happen at opposite ends of the year. Schedule against a named zone, not a frozen number.

The span of standard offsets -12 +14 UTC 0 LA-8 NY-5 London Berlin +1 Dubai+4 India +5:30 Tokyo+9 Sydney +10 Standard time positions. Source: List of UTC offsets. Checked 2026-07-26.

Standard UTC offsets

OffsetExample locations (standard time)
UTC-12:00Baker Island, Howland Island
UTC-11:00Pago Pago (American Samoa), Niue
UTC-10:00Honolulu, Papeete (Tahiti)
UTC-09:00Anchorage
UTC-08:00Los Angeles, Vancouver, Tijuana
UTC-07:00Denver, Phoenix, Calgary
UTC-06:00Chicago, Mexico City, Guatemala City
UTC-05:00New York, Toronto, Bogota, Lima
UTC-04:00Santiago, Halifax, Caracas, La Paz
UTC-03:30St. John’s (Newfoundland)
UTC-03:00Sao Paulo, Buenos Aires, Montevideo
UTC-02:00Fernando de Noronha, South Georgia
UTC-01:00Azores, Cape Verde
UTC+00:00London, Dublin, Lisbon, Accra
UTC+01:00Paris, Berlin, Madrid, Lagos
UTC+02:00Cairo, Athens, Johannesburg, Kyiv
UTC+03:00Moscow, Istanbul, Riyadh, Nairobi
UTC+03:30Tehran
UTC+04:00Dubai, Baku, Tbilisi
UTC+04:30Kabul
UTC+05:00Karachi, Tashkent, Yekaterinburg
UTC+05:30Delhi, Mumbai, Colombo
UTC+05:45Kathmandu
UTC+06:00Dhaka, Almaty, Bishkek
UTC+06:30Yangon
UTC+07:00Bangkok, Jakarta, Ho Chi Minh City
UTC+08:00Shanghai, Singapore, Hong Kong, Perth, Manila
UTC+09:00Tokyo, Seoul, Pyongyang
UTC+09:30Adelaide, Darwin
UTC+10:00Sydney, Brisbane, Port Moresby
UTC+10:30Lord Howe Island
UTC+11:00Noumea, Solomon Islands
UTC+12:00Auckland, Fiji, Tuvalu
UTC+12:45Chatham Islands
UTC+13:00Nuku’alofa (Tonga), Apia (Samoa)
UTC+14:00Kiritimati (Line Islands, Kiribati)

Movers vs fixed

Whether the offset above holds all year depends on daylight saving.

MarketDaylight saving?Effect on schedules
United States (except Arizona, Hawaii)YesClocks move forward in the Northern summer
European Union, United KingdomYesClocks move forward in the Northern summer
Australia (southern states), New ZealandYesClocks move in the Southern summer, opposite months
Chile, parts of South AmericaYesSouthern summer shift
China, Japan, Korea, IndiaNoSame offset all year
Gulf states, most of Africa, IranNoSame offset all year

Scheduling rules that hold up

Frequently asked questions

Why does my scheduled send arrive an hour off in summer?

Daylight saving. The offsets in the table are standard winter time. When a region moves its clocks forward for summer, its offset shifts by an hour. If you scheduled against a fixed offset instead of the named zone, the send drifts by an hour for part of the year.

Which regions do not use daylight saving?

Most of Asia, including China, Japan, Korea and India, plus the Gulf states, most of Africa and Iran. Their offset is the same all year. Within the US, Arizona and Hawaii also stay fixed.

Why are some offsets not whole hours?

A handful of zones sit on the half hour or quarter hour. India is UTC+05:30, Iran UTC+03:30, Afghanistan UTC+04:30, Nepal UTC+05:45 and the Chatham Islands UTC+12:45. Naive schedulers that assume whole-hour offsets get these wrong.

How should I store times for a global store?

Store every timestamp in UTC and convert to the customer's local zone only when you display or send. That keeps records consistent and lets daylight saving be handled once, at the edge, by the named zone rather than a frozen offset.

Sources & data

  1. List of UTC offsets with standard-time example locations, Wikipedia, checked 2026-07-26
  2. Time zone and daylight saving data, IANA Time Zone Database, checked 2026-07-26
Cite this reference: Ecom Almanac (2026). “Time Zones for Campaign Scheduling: UTC Offset Reference.” https://ecomalmanac.com/codes/time-zones-for-campaign-scheduling-utc-offset-reference/