Time Zone Converter

Agarapu Ramesh — Editor and content reviewer

What This Calculator Does

This time zone converter translates a specific date and time from one IANA time zone to another. It displays the converted time along with the UTC offset for both the source and destination zones. The converter handles daylight saving time transitions automatically using the comprehensive IANA time zone database.

Inputs Explained

How It Works

The converter uses the Luxon date-time library, which internally references the IANA Time Zone Database (also known as the Olson database or tzdata). When you select a "From" zone and a "To" zone, Luxon interprets your input datetime in the source zone, converts it to UTC internally, and then converts from UTC to the destination zone. This two-step process through UTC ensures accurate conversion even when daylight saving transitions differ between zones.

Formula Used

Converted Time = Input Time − Source UTC Offset + Destination UTC Offset
(Internally: Input → UTC → Destination zone)

Convert date and time between different locations.

Step-by-Step Example

Input: January 31, 2026, 10:00 AM

From Zone: America/New_York (UTC−05:00 in January, Eastern Standard Time)

To Zone: Asia/Kolkata (UTC+05:30, India Standard Time)

Step 1: Convert 10:00 AM EST to UTC → 10:00 + 5:00 = 15:00 UTC.

Step 2: Convert 15:00 UTC to IST → 15:00 + 5:30 = 20:30 IST.

Result: 8:30 PM on January 31, 2026 in India (same day, 10.5 hours ahead).

Use Cases

Assumptions and Limitations

Frequently Asked Questions

Pick UTC as the source zone, choose your local zone (or let the tool detect it from your browser) as the destination, then enter the date and time. The converter applies the right offset for that specific date — important because daylight saving time can shift it by an hour. So 14:00 UTC becomes 19:30 in India (UTC+5:30, no DST), 09:00 in New York during winter, or 10:00 during US summer. Always include the date — same UTC time can convert to different local times depending on the season.
A good one does, as long as it uses the IANA time zone database. The trick is that DST isn't a single fixed offset — it depends on the date. New York is UTC-5 in January but UTC-4 in July. So when you convert a time, the tool checks which rule applies on that exact date and uses the right offset. If the tool just uses static offsets like "EST" without dates, it can be wrong by an hour. Always pick a converter that asks for the date, not just the time.
India sits at UTC+5:30 all year (no daylight saving). New York switches between UTC-5 in winter and UTC-4 during US daylight saving (roughly mid-March to early November). So the gap between New York and India is 10.5 hours during US winter and 9.5 hours during US summer. India is always ahead. So 9:00 AM in New York is 7:30 PM in India in winter and 6:30 PM during summer. This is why scheduling cross-country meetings benefits from a converter that handles the date, not just a fixed rule.
Start by picking the meeting time in the host's zone — usually the person organising. Convert that to every attendee's zone and check whether it lands inside their working hours. The sweet spot for India–US calls is usually early morning India time (which is evening in the US), and for India–Europe it's afternoon India time. If nothing works for everyone, rotate who takes the awkward slot week to week. Always send invites with the time zone shown explicitly so calendar apps convert correctly for each person.
UTC offset is how far a local time zone is ahead of or behind Coordinated Universal Time, written as hours and minutes. India is UTC+5:30, meaning Indian time is 5 hours and 30 minutes ahead of UTC. New York during standard time is UTC-5, so it's 5 hours behind. The offset can change during the year if the country observes daylight saving — that's why London is UTC+0 in winter but UTC+1 in summer. Knowing your offset is the quickest way to convert between any two zones.
History and geography, mostly. India picked UTC+5:30 as a compromise between the eastern and western parts of the country instead of using two separate zones. Iran uses UTC+3:30, Afghanistan UTC+4:30, and Myanmar UTC+6:30 for similar reasons. Nepal goes even further with UTC+5:45 — the only country using a 45-minute offset, set so its national time is centred on Kathmandu. These weren't accidents — governments chose them to keep daylight aligned with daily life across the country, even if it makes international scheduling slightly more awkward.
EST (Eastern Standard Time, used in winter) is UTC-5, and IST (Indian Standard Time) is UTC+5:30. Add 10 hours and 30 minutes to EST to get IST. So 9:00 AM EST is 7:30 PM IST the same day. But during US daylight saving (March to November), New York shifts to EDT (UTC-4), and the gap shrinks to 9 hours and 30 minutes — making 9:00 AM EDT equal to 6:30 PM IST. Always confirm whether the US is on standard or daylight time before converting; the date matters.
PST (Pacific Standard Time) is UTC-8, and GMT is UTC+0, so add 8 hours to PST to get GMT. 3:00 PM PST becomes 11:00 PM GMT the same day. During US daylight saving, the West Coast switches to PDT (UTC-7), and you only add 7 hours — so 3:00 PM PDT is 10:00 PM GMT. The UK also uses BST (UTC+1) during their summer, which can complicate things further. Use a date-aware converter rather than memorising a fixed offset, especially for meetings around DST transition weekends.
The IANA time zone database (also called tzdata or the Olson database) is the global reference that software uses to handle time zones correctly. It tracks every zone's current offset, daylight saving rules, historical changes (some countries shift their rules every few years), and edge cases. When you see zone names like "Asia/Kolkata" or "America/New_York", those come from IANA. Operating systems, browsers, programming languages and good time zone converters all rely on it, which is why they stay accurate even when a country suddenly changes its DST policy.
Use a converter that handles dates, not just zone names — that's the main thing. On the spring-forward day, clocks usually skip an hour (2:00 AM jumps to 3:00 AM in many places), so any "local time" between those two values technically doesn't exist. On the fall-back day, the same hour repeats. If you're scheduling a meeting on a transition day, pick a time well clear of the changeover. The converter applies the right offset based on the date you enter, but unusual local times near the switch can still get ambiguous.

Sources and References

Related Calculators