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
- Offset: UTC+3:30
- Time zones with this offset: 1 (Asia/Tehran)
- Daylight saving time: none of these zones observe it — the offset stays the same all year.
Cities in UTC+3:30
- Tehran Iran
- Mashhad Iran
- Isfahan Iran
- Karaj Iran
- Tabriz Iran
- Shiraz Iran
- Qom Iran
- Ahvaz Iran
- Kermanshah Iran
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.