5.0 out of 5 — 300654 votes

GMT+3:30 Time Zone Countries list - UTC+3:30 Time Now

UTC+3:30 is three and a half hours ahead of Coordinated Universal Time: 15:00 UTC is 18:30 here. One country uses it — Iran — which makes it the simplest offset on the map to describe and one of the easiest to get wrong in software.

UTC+3:30

Friday, 4 September 2026

UTC+3:30 · Asia/Tehran

Shown for Asia/Tehran — one of the zones with this offset

Cities in UTC+3:30

Countries in UTC+3:30

Neighbouring offsets

World time zone map · All UTC offsets · Time by country

UTC+3:30 time now

Add three hours and thirty minutes to UTC. If UTC shows 09:15, Iran shows 12:45. The half hour is the part people drop, usually by rounding to UTC+3 or UTC+4 and arriving either side of the meeting.

Where UTC+3:30 applies

The list is short, and it has no exceptions: Iran — the entire country, on a single offset with no internal zones. Tehran — the capital and largest city. Mashhad, Isfahan, Shiraz, Tabriz, Karaj, Qom, Ahvaz — all on the same clock as Tehran.

Iran is wide enough east to west that a strict solar reckoning would suggest more than one zone, but the country runs on one, placed at the half-hour rather than the hour.

Daylight saving: ended

Iran used to observe daylight saving, moving to UTC+4:30 for the warmer months and back again. It stopped doing so, and the clock now stays at UTC+3:30 in every month of the year. This is worth checking in any software you inherit. Older time zone data, hard-coded conversion tables and hand-written offset lists frequently still contain the summer rule, which means they will silently place Tehran an hour ahead for part of the year. Systems that use an up-to-date IANA time zone database and the identifier Asia/Tehran handle it correctly; systems that store a raw offset do not.

An offset that is fixed is easy. An offset that used to move is the dangerous kind — somewhere in your stack there is a table that never got the news.

The half-hour problem

Offsets that are not a whole number of hours cause a particular class of scheduling error, because so much informal timekeeping assumes hours are the atomic unit. Rounding. A conversion done in the head from UTC+3 or UTC+4 lands thirty minutes off, and thirty minutes is small enough that both parties assume the other is merely late.

Meeting slots. A working day divided into hour blocks in one zone maps onto half-past starts in Iran. Book the block, not the hour. Cron and timers. Schedules written against whole hours in UTC fire at :30 local. Usually harmless, occasionally not.

Storage. Persist an instant plus a zone identifier, not an offset in hours. An integer field for hours cannot hold this zone at all. The Iranian calendar adds a second layer: the country uses the Solar Hijri calendar for civil purposes, so a date converted correctly can still be labelled unfamiliarly. The offset and the calendar are separate problems and need separate handling.

Questions and answers

UTC+3
Thirty minutes behind. Moscow, Istanbul, Baghdad, Riyadh and Nairobi.
UTC+4
Thirty minutes ahead. Dubai, Baku, Tbilisi and Yerevan.
UTC+4:30
One hour ahead. Afghanistan — and Iran's own former summer position.
Does Iran still switch to UTC+4:30 in summer?
No. Iran discontinued daylight saving and now stays on UTC+3:30 year-round. Software or documents showing a summer shift are out of date.
Does any country other than Iran use UTC+3:30?
No. It is a single-country offset, which is unusual even among the half-hour zones.
How do I store this offset correctly in an application?
Store a UTC instant together with the IANA identifier Asia/Tehran, and let the time zone library resolve the offset. Storing "+3.5" or an integer number of hours will break, either now or the next time the rules change.
All pages