Time Zone Converter

Time zones are a political artefact wearing an astronomical costume, which is why they are harder than they look.

Offsets are not zones

An offset is a number: +5:30, −8:00. It describes a moment.

A time zone is a set of rules across history: which offset applies, when it changes, and how it has changed in the past. Asia/Kolkata is a zone; +5:30 is what it happens to be right now.

The distinction matters because zones change. India has used several offsets historically; Samoa skipped 30 December 2011 entirely when it moved across the international date line; Russia has changed its zone rules repeatedly. A stored offset is a snapshot; a stored zone name survives the rules changing.

The IANA Time Zone Database is the authoritative record, updated several times a year as governments make changes — sometimes with only weeks of notice.

India, and why the gap moves

India runs UTC+5:30, one zone for the entire country, with no daylight saving.

Because other countries do observe it, the gap between India and them changes twice a year without anything changing in India:

Sydney runs the other way because Australian daylight saving falls in the southern summer, which is the northern winter — so the gap to India is widest in January and narrowest in July.

A recurring 6 pm IST call with London is 12:30 pm there in winter and 1:30 pm in summer, and nobody moved it. This is the single most common scheduling problem for Indian teams working with Europe and the US, and it appears twice a year without warning.

Note also that the changeover dates differ: Europe switches in late March and late October; the US in mid-March and early November. For two weeks each spring the US and Europe are out of step with each other, which produces a brief window when a three-way call has an unfamiliar shape.

Single-zone India is itself a compromise. The country spans about 30 degrees of longitude, so the sun rises nearly two hours earlier in Arunachal Pradesh than in Gujarat. Proposals for a second zone recur and have not been adopted.

Daylight saving

Roughly seventy countries observe it, and the details vary.

Northern hemisphere: forward in spring, back in autumn.

Southern hemisphere: the reverse, so Australia and Brazil shift in the opposite months.

Most of Asia and Africa: none at all.

Two consequences that break software.

Spring forward creates a gap. When clocks jump from 2:00 to 3:00, the hour between does not exist. A job scheduled at 2:30 local time simply does not run.

Autumn back creates an overlap. 1:30 happens twice, and a timestamp stored without an offset is ambiguous — there is no way to tell which occurrence it was.

This is why financial systems, logs and anything auditable store UTC. There is no gap and no overlap in UTC, ever.

The EU voted in 2019 to abolish seasonal changes and has not implemented it. Various US states have passed permanent daylight saving laws that require federal approval they do not have. Both are worth knowing about only because they mean the rules may change again.

The offsets that break assumptions

Whole-hour offsets are not universal.

Any code that models an offset as an integer number of hours is wrong for about a fifth of the world's population, and India is the largest part of it.

The extremes are also further apart than 24 hours. Kiribati's Line Islands are UTC+14 and Baker Island is UTC−12, so there is a 26-hour span and three different calendar dates can be in progress simultaneously.

Handling time in software

Four rules cover most of it.

Store in UTC. Convert for display only. A timestamp in the database should be unambiguous.

Store the zone name, not the offset, where the local time matters — a recurring appointment, a business's opening hours. Asia/Kolkata survives a rule change; +5:30 does not.

Never store a local time alone. "2026-09-06 14:00" without a zone cannot be interpreted, and the information is not recoverable later.

Use a library. Time zone arithmetic is genuinely difficult and the rules change several times a year. The modern JavaScript approach is Intl.DateTimeFormat with a named zone, and Temporal where available. Rolling your own offset arithmetic is how the twice-yearly bug gets written.

For a recurring event, the correct model is a local time plus a zone plus a recurrence rule. Storing the first occurrence's UTC timestamp and adding seven days makes the meeting move an hour when the clocks change.

Scheduling across zones

Name the zone, always. "3 pm IST" rather than "3 pm". Abbreviations are ambiguous — CST is Central Standard Time in the US, China Standard Time and Cuba Standard Time.

Use a calendar invite rather than a message. It converts for each attendee and follows daylight saving automatically.

Find the overlap deliberately. India and the US west coast share very little working day: 9 am to 6 pm IST is 8:30 pm to 5:30 am in California. Something has to give, and deciding what in advance is better than discovering it weekly.

Watch the changeover weeks. A meeting set in October across Europe and the US will land differently for two weeks. Reconfirm around those dates.

Prefer asynchronous work where the overlap is under two hours. Three hours of overlap can support a daily call; forty minutes cannot, and pretending otherwise costs someone their evening.

UTC, GMT and the leap second

UTC — Coordinated Universal Time — is the modern standard, maintained by atomic clocks and adjusted occasionally to stay near the Earth's rotation.

GMT — Greenwich Mean Time — is an older astronomical standard. In casual use the two are treated as the same, and for scheduling they are. In technical contexts UTC is the correct term, and the UK's civil time is GMT in winter and British Summer Time in summer, which is a separate matter from the standard itself.

Zulu time, written with a trailing Z on a timestamp, is UTC. 2026-09-06T10:30:00Z is unambiguous and is the form to use in any data interchange.

Leap seconds are the awkward part. The Earth's rotation is not perfectly regular, so a second is occasionally inserted into UTC to keep it aligned — producing a minute with 61 seconds. Systems that assume 60 have failed on leap second days, notably several large outages in 2012 and 2015.

Some large operators now "smear" the leap second across a day rather than inserting it, which keeps clocks monotonic at the cost of being slightly wrong for 24 hours. The international timekeeping bodies have agreed to stop adding leap seconds by 2035, which will eventually remove the problem and does not help anything running before then.

Practical patterns for teams

Publish everyone's zone somewhere visible. A shared page listing each person's zone and working hours removes most of the guessing, and it needs updating when someone moves.

Set a core overlap — two or three hours when everyone is expected to be available — and treat the rest of the day as asynchronous. This is more honest than pretending the whole day is shared.

Rotate the inconvenience. Where a recurring call cannot suit everyone, moving which team takes the awkward slot spreads the cost rather than concentrating it on whoever is furthest from headquarters.

Write dates unambiguously. 06/09/2026 is 6 September in India and the UK and 9 June in the US. ISO format — 2026-09-06 — is unambiguous everywhere, sorts correctly as text, and is worth adopting for anything crossing a border.

What this tool assumes

• Current IANA time zone rules, which are updated several times a year as governments change them.
• Daylight saving is applied automatically for the date you select, so a conversion for a future date uses the rules known today.
• Zone names rather than fixed offsets, so historical dates use the rules that applied then.
• Abbreviations are ambiguous and are resolved to the most common zone; specify the full zone name where it matters.
• Everything runs in your browser using its own time zone data.