What this tool is for
This reference lays out every UTC offset in use, from the far western Pacific at UTC-12:00 to the far eastern Pacific at UTC+14:00, alongside the countries and territories that observe each one. It is built for anyone reasoning about time across regions: scheduling calls, configuring servers, debugging distributed logs, or sanity-checking date arithmetic.
How it works
An offset is simply the signed number of hours and minutes a location’s clock runs ahead of or behind UTC at a given moment. The table stores each offset in minutes so it can represent half-hour and quarter-hour zones precisely, then derives the live local time by adding the offset to the current UTC instant from your browser.
The range deliberately exceeds twelve hours in both directions. The international date line bends around national borders, and territories such as Kiribati’s Line Islands chose UTC+14:00 so the entire country keeps one calendar day. That is why the span is 26 hours wide rather than 24.
The non-whole-hour offsets that break naive code
Most people assume time zone offsets are whole hours. Several places prove that wrong:
| Territory | Offset | Why it exists |
|---|---|---|
| India | UTC+05:30 | British colonial compromise between two proposed whole-hour zones |
| Iran | UTC+03:30 | Standard time; shifts to UTC+04:30 in summer |
| Afghanistan | UTC+04:30 | Unchanged since 1945 |
| Nepal | UTC+05:45 | Set in 1956, differs from India by 15 minutes |
| Chatham Islands (NZ) | UTC+12:45 | 45-minute difference from mainland New Zealand |
| Lord Howe Island (AU) | UTC+10:30 | 30-minute difference from mainland Australia |
These are not bugs in the data — they are deliberate political or historical choices. Any code that derives local time by dividing an offset by 60 and treating the remainder as a whole-number offset will produce wrong results for these regions. Always represent offsets in minutes and use a library (such as Temporal or date-fns-tz) that handles them correctly.
Offset versus time zone — an important distinction
The terms are often used interchangeably but they mean different things:
- An offset is a fixed number like
+05:30. It describes the difference from UTC at one moment. - A time zone is a named region with a history of rules — when clocks change, by how much, and since when.
Asia/Kolkatais a time zone;+05:30is its current offset.
The same offset is shared by many time zones, and the same time zone can have different offsets throughout the year due to daylight saving. For scheduling across regions, you almost always want a time zone identifier (from the IANA tz database), not just an offset, because offsets alone do not tell you what will happen when clocks change next month.
Why distributed systems developers need this reference
When debugging logs from servers in different regions, all timestamps should be stored in UTC and converted for display. If they are not, offsets become critical for correlating events:
- A log entry at
14:30:00 +05:30occurred at the same instant as09:00:00 UTC. - If one service logs in UTC and another in local time, the apparent 5.5-hour gap is an artifact of offset differences, not a real delay.
For APIs that accept or return time data, the ISO 8601 convention is to include the offset inline (2024-03-15T14:30:00+05:30) so consumers can always compute UTC equivalence without knowing the caller’s time zone.
Tips and notes
Never assume offsets are whole hours. India sits at UTC+05:30, Nepal at UTC+05:45, and the Chatham Islands at UTC+12:45, so always store offsets in minutes and let a proper date library handle arithmetic. Remember too that the territory list reflects standard time: during daylight saving a region shifts to the next offset up, which is why a single country can appear to move between rows across the year.