Time Zone Converter
Convert a date and time from one city to another, with daylight saving resolved live from the IANA time zone database.
Formula last reviewed 15 September 2026 · How we verify our calculators
Time in India
1:30 PM
- Full date & time
- Mon, 15 Jun 2026 13:30
- London zone
- GMT+1
- India zone
- GMT+5:30
Updates live as you type
Frequently asked questions
It resolves each city’s offset from the IANA time zone database for the exact date you enter, so a date in summer uses the daylight-saving offset and a winter date uses the standard one — automatically.
Pick the time with the 12-hour hour/minute selectors and the AM/PM toggle, then choose the date. Results are shown in 12-hour format too, with a 24-hour toggle available.
When the offset gap is large enough, the converted time can land on a different calendar day. The label flags when the result rolls into the previous or next day.
No. India uses a single zone, IST (UTC+5:30), with no daylight saving, so conversions involving India shift only by the other city’s seasonal changes.
1:30 PM in India, and why the offset is not fixed
Converting London to India on 15 June 2026 gives 1:30 PM in India — because London is on GMT+1 in June, not GMT.
That qualification is the entire reason this tool resolves times against the IANA database rather than applying a stored offset. London is UTC+0 in winter and UTC+1 in summer, so the gap to India is 5.5 hours for part of the year and 4.5 hours for the rest. A converter using a fixed number is wrong for roughly half of every year.
How the conversion works
Three steps, always:
1. Take the entered local time in the source zone and resolve it to an absolute UTC instant, using the source zone's offset on that specific date. 2. Apply the target zone's offset on that same instant. 3. Render the result, noting any date change.
Because both offsets are looked up per-date, the conversion stays correct across daylight saving transitions in either zone, and across historical rule changes.
Date changes are common and easily missed. 9:00 PM in Los Angeles is 9:30 AM the *next day* in India. Any meeting scheduled across a large gap needs the date confirmed as explicitly as the time.
The two hours that do not behave
Daylight saving transitions create two genuine edge cases, and they are the reason naive conversion code fails.
The spring skip. When clocks jump forward, an hour does not exist. In the UK on the last Sunday in March, 01:30 simply never occurs. A time entered in that window has no valid instant, and implementations either reject it or shift it forward.
The autumn repeat. When clocks go back, an hour occurs twice. On the last Sunday in October, 01:30 happens once at UTC+1 and again an hour later at UTC+0. A bare local time in that window is genuinely ambiguous — it maps to two different instants, and the usual convention is to take the first.
This is why storing meeting times as local wall-clock strings causes problems, and why systems that need to be right store the UTC instant plus the zone identifier instead.
IST, and the abbreviation problem
IST is one of the more troublesome abbreviations in scheduling, because it means India Standard Time (UTC+5:30), Irish Standard Time (UTC+1) and Israel Standard Time (UTC+2) depending on who wrote it.
CST is worse still — US Central, China Standard and Cuba Standard all claim it.
Abbreviations are not standardised and not unique. For anything that matters, use the city or the IANA zone name: `Asia/Kolkata` is unambiguous in a way that "IST" is not.
What to use this for
Scheduling calls with clients, colleagues or family abroad, with the date confirmed.
Catching a market open or close — NSE, LSE, NYSE and the crypto markets that never close.
Flight arrival planning, where timetables are published in local time at each end and the elapsed journey is not the clock difference.
Deadline compliance, where a submission closes at a stated hour in a stated zone.
Coordinating releases across a distributed team.
Common mistakes
Using a remembered offset. It changes twice a year for most of the world.
Ignoring the date change. Large gaps routinely push the result into the next or previous day.
Trusting an abbreviation. IST and CST each mean several different things.
Scheduling in the DST transition window. Those local times are skipped or duplicated.
Assuming both ends switch together. The US, EU, Australia and others all change on different dates, so the gap between two cities can be unusual for weeks at a time.