Time Zone Converter

What is a time zone converter?

A time zone converter takes a clock time in one location and tells you what the clock reads at the same moment in another location. "It's 3 PM in New York — what time is it in Tokyo?" That's the whole job. The math seems easy until you remember that the Earth has 38 active time zones (not 24, as people often assume), most of them shift for daylight saving time on different dates, and a handful are offset by 30 or 45 minutes from the next zone over. Doing this by hand reliably is harder than it looks.

The reason there are 38 time zones rather than 24 is that countries set their own clocks for political and practical reasons, not just for sunlight alignment. India sits at UTC+5:30. Nepal is at UTC+5:45, the only country in the world offset by 15 minutes plus 30. China runs on a single time zone for the entire country, even though geographically it spans five. The system is messy because the world is messy.

The Time Zone Converter handles all of this for you. It uses the same time zone database that Linux, macOS, Windows, iOS, and Android use — the IANA tz database — which is maintained by a small group of volunteers and updated several times a year as countries change their rules. You don't have to think about DST start dates or 30-minute offsets; the converter applies the right rule for the date you pick.

How to use the Time Zone Converter

The Time Zone Converter uses three inputs and an output list.

1. Pick the source time zone — usually wherever you are right now, or the location of the person you're scheduling with.
2. Pick the source time and date. Date matters because daylight saving rules can flip the offset by an hour.
3. Pick one or more target time zones. You can compare several at once, which is the point.
4. Read the resulting times. If a target zone crosses midnight relative to the source, the date shifts up or down — the converter shows you "+1 day" or "-1 day" so you don't miss it.

The converter defaults to the time zone your browser reports, so the first row is usually pre-filled with your local time. Everything runs in the browser; nothing about the time you enter or the zones you compare leaves the page.

UTC: the reference clock for everything

Underneath every time zone is a single global reference: Coordinated Universal Time, abbreviated UTC. UTC is roughly aligned with the local time at the Royal Observatory in Greenwich, England — close enough that you'll see it called GMT (Greenwich Mean Time) in casual use, though the two aren't quite identical at the millisecond level.

Every time zone is defined as an offset from UTC. New York in winter is UTC−5; Paris in winter is UTC+1; Tokyo year-round is UTC+9. To convert between any two zones, you can take the long way around through UTC:

This is what the converter does internally. It converts the source time to UTC, applies the target offset, and shows you the result. The arithmetic is straightforward once you know the offsets; the work is keeping track of which offsets apply on which dates, which is where the IANA database earns its keep.

A worked example: scheduling a call across four cities

Say it's a Tuesday in October. You're in New York and want to schedule a call at 3 PM your local time. The other participants are in London, Paris, and Tokyo. What time does the call start for each of them?

In October, North America and Europe are both on their summer schedules (EDT and BST, respectively); the southern-hemisphere zones aren't yet on summer time. The offsets that apply are:

• New York: EDT, UTC−4
• London: BST, UTC+1
• Paris: CEST, UTC+2
• Tokyo: JST, UTC+9 (no DST)

Step by step: 3 PM New York = 3 PM + 4 hours = 7 PM UTC. From there, add each target offset:

So 3 PM Tuesday New York is 4 AM Wednesday Tokyo. That's a meeting Tokyo isn't going to attend cheerfully. The honest answer when you see numbers like this is to pick a different time — 8 AM New York would be 9 PM Tokyo, which is much friendlier across the Pacific.

The date shift is the part that catches people. A meeting time looks fine until you realize it falls on a different calendar day for some participants. Always confirm the date as well as the hour when scheduling across more than 6 hours of offset.

Daylight saving time: the source of most errors

Daylight saving time is what makes time zone conversion genuinely hard. The rules aren't standardized across the world, and a few countries change them every few years. Here's the pattern as of late 2025:

Three things to notice. First, US and EU DST start and end dates are off by a week or two — there's a window in March when the US has switched and the EU hasn't, so New York and London are only 4 hours apart instead of the usual 5. The same gap appears in October-November. Second, the southern hemisphere does the opposite — its summer (and therefore its DST) runs October through April. Third, large chunks of the world ignore DST entirely, which is honestly a lot easier on everyone scheduling across them.

The practical effect: a meeting that's at 9 AM New York / 2 PM London for most of the year suddenly becomes 9 AM New York / 1 PM London for two weeks in March, and 8 AM New York / 2 PM London for one week in November. The Time Zone Converter handles this automatically by using the date you specify, so the answer is always correct for that specific day.

Major city offsets at a glance

A reference table for the cities that come up most often in scheduling. These show the standard time offset (winter for the northern hemisphere); add or subtract one hour during the relevant DST window.

The 30-minute and 45-minute zones

India, parts of Australia, Iran, Afghanistan, Nepal, Myanmar, the Marquesas Islands, and a few others use offsets that aren't whole hours. The historical reason is usually political: when railways forced standardization in the late 1800s, each country had to pick an offset, and a few chose the local solar mean time over the nearest whole-hour zone. Nepal's UTC+5:45 was set in 1986 to put the country exactly between India (UTC+5:30) and Bhutan (UTC+6) — a small assertion of independence written into the clock.

If you schedule with someone in any of these zones, watch for "half-past" times in unexpected places. A 9 AM call in London is 2:30 PM in Mumbai, not 2 PM. Off-by-thirty errors are a common scheduling mistake when one party assumes whole-hour offsets everywhere.

Where time zone errors really cost

A wrong conversion is mostly an inconvenience — you miss a call, reschedule, apologize. But there are a few places where it costs real money or worse.

• Flight bookings. Airlines display arrival times in local time at the destination. A flight that "arrives at 8 AM" can be 18 hours of clock time if you're crossing 10 zones — the duration isn't 8 minus the departure hour.
• Server logs and incident response. Production systems run on UTC for a reason. Mixing UTC, local time, and "the time the screenshot was taken" turns a 20-minute incident into a 2-hour archaeology project.
• Cron jobs and scheduled tasks. "Run at 3 AM" needs to specify whose 3 AM. A misconfigured server timezone can run nightly batches at the wrong time and silently corrupt a week of data.
• Stock and crypto trading. Market opens and closes are in local exchange time, which DST shifts twice a year. Algorithms with hard-coded UTC offsets break in March and November.
• Healthcare scheduling. Cross-zone telehealth appointments need explicit zone labeling. "3 PM appointment" without a zone has caused more than one missed surgery prep call.

Related tools

Time zone conversion is the headline question, but it often sits next to other clock and calendar problems:

• Unix Timestamp Converter — converts between human-readable dates and the Unix epoch (seconds since 1970-01-01 UTC). The format every server and database actually uses underneath.
• Date & Time Calculator — does arithmetic on dates and clock times (add 14 days, subtract 6 hours, find the difference between two timestamps).
• Days Between — calculates the number of days between any two dates, with optional inclusion of business days only.
• Hours Calculator — adds and subtracts hours and minutes, useful for billing and timesheet work alongside zone conversion.

Frequently asked questions

How does the converter know about DST changes?

It reads from the IANA time zone database (sometimes called the "tz database" or "zoneinfo"), which is the same database every major operating system uses. When a country changes its DST rules, the IANA maintainers publish an updated dataset, usually a few weeks before the change takes effect. The browser carries a recent copy of this data; the Time Zone Converter reads it for the date you select.

What about countries that abolished DST recently — does the converter handle that?

Yes, as long as the IANA database has the change recorded. Russia dropped DST in 2011, Turkey in 2016, Brazil in 2019, and several others. The converter applies the correct rule for the date you pick, so historical dates use the historical rules and current dates use the current rules. The one place this gets wobbly is for very recent rule changes that haven't propagated to all systems yet — if a country announces a switch with only a few weeks' notice, browsers may take a release cycle or two to catch up.

What's the difference between EST, EDT, and ET?

EST is Eastern Standard Time (UTC−5), used in the eastern US during winter. EDT is Eastern Daylight Time (UTC−4), used during summer DST. ET is the generic label that covers both — it just means "whichever is currently active in the US Eastern zone." If you're scheduling, "ET" is usually safer than "EST" because it doesn't lie during summer.

Does the converter work for historical dates?

Within the limits of the IANA database, yes. The database has reasonably good rule data going back to the early 1900s for most countries. Very old dates (pre-1900) or obscure historical zones may use approximate rules, since the actual local-time definitions weren't standardized then.

Why is there sometimes a 30-minute offset between countries?

A handful of countries — India (UTC+5:30), Iran (UTC+3:30), Afghanistan (UTC+4:30), Myanmar (UTC+6:30), Sri Lanka (UTC+5:30), the Marquesas Islands (UTC−9:30), parts of Australia (UTC+9:30), and Newfoundland (UTC−3:30) — use half-hour offsets. Nepal goes further with UTC+5:45. The historical reasons vary: most chose the offset that matched local solar noon when railways forced standardization. The converter handles all of them automatically.

Should I store times in UTC or local time?

For anything stored in a database or sent between systems, store UTC. Convert to local time only at display time, and always alongside the user's current time zone. Storing local time without a zone label is the cause of most time-zone bugs in working software — the data looks fine until DST flips and suddenly half the records are an hour off.

What's the largest time difference between two inhabited places?

About 26 hours, between the Line Islands (Kiribati, UTC+14) and American Samoa (UTC−11). Both places are inhabited, both have airports, and they're roughly 2,000 miles apart in the Pacific. When it's noon Tuesday in Kiritimati, it's 10 AM Monday in Pago Pago — same instant in time, but the calendar dates differ by more than a day. This kind of edge case is why the converter shows day shifts explicitly with "+1 day" or "-1 day" labels.

Why does my computer's clock sometimes show the wrong time after travel?

Most modern operating systems auto-detect time zone from network signals or location data, but the detection isn't instant. After a flight, the laptop usually catches up within a few minutes; phones with GPS are faster. If the clock seems stuck, restarting the network connection or toggling the time zone setting forces a refresh. The underlying clock (UTC) is correct; only the displayed local time is wrong.