The most expensive meeting I ever missed was scheduled correctly. Someone in London put "3pm my time, 10am yours" in a calendar invite to me in New York, which was true when they wrote it in February. The call was on 12 March. The United States had moved its clocks forward the previous Sunday; the United Kingdom had not, and would not for another three weeks. The gap between London and New York, normally five hours, was four that week — so 3pm in London was 11am for me, not 10am. I joined an empty room an hour early, gave up, and missed the call entirely.
That three-week window in spring — and the one-week window in autumn — is not an edge case. It happens every single year, and it catches people who are otherwise perfectly competent at arithmetic, because the arithmetic is not the problem. The problem is that "London is five hours ahead of New York" is not a fact about two cities. It is a fact about two cities on a particular date, and the moment you write it down without the date attached, you have created a bug.
A time zone is not an offset. It is a set of rules that produce an offset when you feed it an instant. Those rules change: countries adopt daylight saving, abandon it, shift their standard offset, or announce a permanent change with three weeks' notice. This is why the Time Zone Converter on toolz.dev never stores an offset anywhere. It asks the IANA time zone database — the one already sitting inside your browser — what the offset is for the exact moment you are converting, and it asks again for every other moment.
TL;DR: The gap between two zones depends on the date, because daylight saving transitions do not line up between countries. The Time Zone Converter resolves every offset through the IANA database for the specific instant you enter, shows both UTC offsets and the signed difference, handles half-hour and quarter-hour zones, and lays the same instant across several cities in a meeting-planner strip. It runs entirely in your browser.
Key Features
Offsets resolved per instant, never hardcoded
Every offset in this tool is computed by formatting your instant into the target zone and reading the wall clock back. That single design decision means daylight saving, historical rule changes, and countries that adjust their offset by government decree are all handled by the same code path. There is no offset table to maintain and no table to go stale. Convert a meeting in January and the same meeting in July between Berlin and Chicago, and the tool will correctly give you a seven-hour gap both times — but convert one in late March and it will correctly give you six.
More than 50 curated IANA zones
The picker lists the cities people actually schedule around, grouped by region, labelled with their country, and shown alongside the full IANA identifier. That last part matters more than it looks: Asia/Kolkata is the string you paste into a cron expression, a Postgres AT TIME ZONE clause, or a Python ZoneInfo constructor. Reading "Kolkata, India" and copying Asia/Kolkata are two different jobs, and the tool does both.
A meeting planner strip
Below the conversion, each zone you add gets a row of hour cells spanning the window around your instant. Working hours (09:00 to 17:59 local) are shaded, early and late hours are marked separately, and any cell that falls on a different calendar day carries a +1d or -1d badge. Finding an hour that is civilised in San Francisco, London, and Sydney simultaneously is a hard problem — the strip makes it a visual one instead of an arithmetic one.
Half-hour and quarter-hour zones treated as normal
India is UTC+05:30. Nepal is UTC+05:45. Adelaide is UTC+09:30 in winter and UTC+10:30 in summer. The Chatham Islands are UTC+12:45. Roughly a fifth of the world's population lives on an offset that is not a whole number of hours, and any tool that assumes otherwise is wrong for hundreds of millions of people. Offsets here are stored and displayed in minutes.
Abbreviations shown for the date you entered
Each side of the conversion displays the zone abbreviation in force at that instant — EST or EDT, GMT or BST, AEST or AEDT. This is the quickest way to see which side of a transition you landed on. If you entered a March date and the tool says EDT, the clocks have already changed. If it says EST, they have not.
Fully client-side
Every calculation runs in JavaScript in your browser, using the Intl API and the time zone database that ships with the engine. Nothing you enter is uploaded, nothing is logged, and once the page has loaded the converter keeps working with no network connection at all. That also means the result updates the instant you change a field, because there is no round trip to wait for.
How to Use the Time Zone Converter
Step 1: Set the source zone, date, and time
Pick the city you are converting from, then enter the date and the time exactly as the clock reads there. The time field takes a 24-hour value, so 3pm is 15:00. If you want the current moment rather than a hypothetical one, press Now — it loads the present date and time as seen in the source zone, which is not necessarily the same date as the one on your own wall.
Step 2: Pick the target zone
Choose the city you want the answer in. The converted date, time, and 12-hour reading appear immediately, along with the UTC offset and abbreviation that apply on that particular date. Note that the date can change: 21:00 on Monday in New York is 07:00 on Tuesday in Dhaka, and the tool shows the new date rather than quietly leaving you to work it out.
Step 3: Read the offsets and the gap
Under each side you get the offset in UTC±HH:MM form and the zone abbreviation. Between them, the tool states the relationship in words — "Dhaka is 10 hours ahead of New York" — with the correct value for that date, not a memorised average. Use the swap button to reverse the direction; it keeps the same instant and flips which side you are entering, which is what you almost always want.
Step 4: Build the meeting strip
Add every participant's zone to the planner. Each row shows the same instant in that zone plus the hours around it, with working hours shaded. Slide your source time earlier or later and watch the shading move. When the shaded cells line up in every row, you have found your slot.
Step 5: Copy the result
Copy just the converted time, or the full expression — Sun, Mar 12, 2026 09:00 EDT (America/New_York) = Sun, Mar 12, 2026 13:00 GMT (Europe/London) — and paste it into the calendar invite. Writing both sides with their abbreviations is the single most effective habit for not repeating my London mistake.
How time zone conversion actually works
The naive mental model is that each zone has a number attached to it and conversion is subtraction. That model is wrong in a way that produces correct answers most of the time, which is the worst possible failure mode.
The correct model has three layers.
Layer one: the instant. Underneath everything is a single point on the universal timeline — an epoch timestamp, a count of seconds since 1970-01-01T00:00:00Z. Instants are unambiguous. Everyone on Earth experiences the same instant simultaneously, whatever their clock says.
Layer two: the offset. An offset is a signed number of minutes to add to UTC to get local wall-clock time. UTC-04:00 is an offset. It is a result, not a property of a place.
Layer three: the zone. A zone is a named set of rules — America/New_York — that maps an instant to an offset. This is the layer that people collapse into layer two, and that collapse is the source of nearly every time zone bug ever written.
So a conversion is not localB = localA + delta. It is:
instant = resolve(wallClockA, zoneA) // rules of A, applied to that reading
wallClockB = render(instant, zoneB) // rules of B, applied to that instant
Two rule lookups, one instant in the middle. The tool does exactly this. To resolve the offset of a zone at an instant, it formats the instant into that zone, reads back the year, month, day, hour, minute, and second, treats those fields as though they were UTC, and subtracts the real instant. The difference is the offset, in minutes, straight from the engine's copy of the IANA database.
Going the other direction — from a wall-clock reading to an instant — has a chicken-and-egg problem, because you need the offset to find the instant and the instant to find the offset. The tool guesses once using the naive offset, checks whether the guess landed on the other side of a transition, and corrects if it did. Two lookups, always terminates, correct across DST boundaries.
The IANA time zone database
The database everything depends on is maintained by IANA and is often still called the "Olson database" after Arthur David Olson, who started it in the 1980s. It ships inside every operating system, every browser, every JVM, and every Python install, and it is updated several times a year because governments keep changing their minds.
Its identifiers take the form Area/Location: America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney. The location is a representative city, not a political claim — America/New_York covers the entire US Eastern zone, and Indiana famously needs a dozen identifiers of its own because its counties disagreed for decades about whether to observe daylight saving.
What the database stores is not a single offset per zone but a full rule history. It knows that Ukraine's Europe/Kyiv was Europe/Kiev until the spelling was updated in 2022. It knows that Egypt reintroduced daylight saving in 2023 after abandoning it in 2014. It knows that Samoa skipped 30 December 2011 entirely when it jumped the International Date Line. That history is why converting a date in 2015 and a date in 2025 for the same pair of cities can legitimately produce different answers, and why a tool that hardcodes offsets is a tool that lies about the past.
The practical consequence for anyone writing software: store instants in UTC, store the user's zone as an IANA identifier, and convert only at the display layer. Never store an offset. An offset is a rendering of a rule, and rules change. If you are working with epoch values directly, the Timestamp Converter is the companion tool for reading them back as dates.
UTC offsets, abbreviations, and zone names: which to use
These three things are constantly confused, and they are not interchangeable.
| Form | Example | Stable? | Unique? | Use it for |
|---|---|---|---|---|
| IANA zone name | America/New_York |
Yes, across DST | Yes | Storage, code, config, APIs |
| UTC offset | UTC-04:00 |
No, changes with DST | No | Display, wire formats with an instant attached |
| Abbreviation | EDT |
No, changes with DST | No | Human-facing display only |
The killer is that last column. Abbreviations are not unique. CST means US Central Standard Time, China Standard Time, and Cuba Standard Time — three different offsets, one string. IST means Indian Standard Time, Irish Standard Time, and Israel Standard Time. BST means British Summer Time, and also Bougainville Standard Time. If a system receives CST over the wire and has to guess, it will guess wrong for somebody.
The offset form is unambiguous but not stable: UTC+01:00 correctly identifies an instant's rendering, but it is not a zone, and you cannot use it to compute next Tuesday's rendering, because next Tuesday may fall on the other side of a transition.
Only the IANA name carries the rules. It is the only one of the three you should ever persist.
Why the gap between two cities keeps moving
Daylight saving is the reason, and the reason it bites so hard is that countries do not synchronise their transitions.
- The United States springs forward on the second Sunday in March and falls back on the first Sunday in November.
- The European Union springs forward on the last Sunday in March and falls back on the last Sunday in October.
- Australia, being in the southern hemisphere, does the opposite: forward in October, back in April — and Queensland, Western Australia, and the Northern Territory do not do it at all.
- India, China, Japan, most of Africa, and most of Asia do not observe it at any point.
Line those up and you get overlap windows where the usual gap is simply wrong:
| Period | New York clock | London clock | Gap |
|---|---|---|---|
| Most of winter | EST (UTC−05:00) | GMT (UTC+00:00) | 5 hours |
| Second Sunday in March → last Sunday in March | EDT (UTC−04:00) | GMT (UTC+00:00) | 4 hours |
| Most of summer | EDT (UTC−04:00) | BST (UTC+01:00) | 5 hours |
| Last Sunday in October → first Sunday in November | EDT (UTC−04:00) | GMT (UTC+00:00) | 4 hours |
Two windows a year — roughly three weeks in spring and one week in autumn — in which every "we're always five hours apart" assumption in your calendar is off by an hour. And that is just one pair of cities. Add Sydney, whose transitions run in the opposite direction, and the number of distinct gap values across a year climbs quickly.
The transitions themselves create two more hazards worth naming. When clocks spring forward, an hour of local time does not exist — 02:30 on the transition night in New York is not a real reading. When clocks fall back, an hour of local time happens twice, and a bare wall-clock reading is genuinely ambiguous. The converter resolves non-existent times to the instant immediately after the transition and ambiguous times to the first occurrence, which is the convention most calendar software follows. It is not the only defensible choice, but it is the one that produces the fewest surprises.
Common use cases
Scheduling meetings across a distributed team. The obvious one, and the one the planner strip exists for. Three or more zones is where mental arithmetic reliably fails, particularly when one of them is on a half-hour offset or in the southern hemisphere.
Writing calendar invites and announcements. Always state the time with a zone, always give at least two renderings, and prefer the IANA name or a fully qualified abbreviation over "my time". "14:00 UTC (10:00 EDT / 19:30 IST)" is unambiguous. "2pm" is a coin flip.
Debugging timestamps in logs. A server logs in UTC, a customer reports an incident in local time, and the two need to be reconciled before you can find the request. Convert the customer's report into UTC, then search. If the logs are epoch values rather than ISO strings, run them through the Timestamp Converter first.
Scheduling cron jobs and background work. A cron expression on a server set to UTC will not shift with a user's daylight saving change, which is usually what you want — and occasionally exactly what you do not, if the job is meant to run at 09:00 local for a customer in a DST-observing country. Work out both readings before you commit the schedule; the Cron Parser will tell you what your expression actually means.
Planning travel and calls with family. Departure and arrival times are always given in local time at each airport, which means a flight's apparent duration is nonsense until you convert both ends to the same zone. A 14-hour flight that "arrives before it departs" is just a date-line crossing.
Coordinating launches, deploys, and embargoes. Anything with a hard cutoff across multiple markets needs a single instant, expressed in UTC, with local renderings attached for each region. If you are computing how many days remain until that instant rather than the clock reading, the Date Difference Calculator is the other half of the workflow.
FAQ
How do I convert EST to IST?
Select America/New_York as the source and Asia/Kolkata as the target. India is 10 hours 30 minutes ahead of New York during Eastern Standard Time and 9 hours 30 minutes ahead during Eastern Daylight Time, because India does not observe daylight saving and the United States does. That shifting gap is exactly why you should convert against a date rather than memorise a single number.
What is the difference between EST and EDT?
EST (Eastern Standard Time) is UTC−05:00 and applies in winter. EDT (Eastern Daylight Time) is UTC−04:00 and applies from the second Sunday in March to the first Sunday in November. "Eastern Time" or ET is the umbrella term meaning whichever is currently in force. In documents and code, prefer the IANA identifier America/New_York, which is unambiguous all year round.
Does this converter handle daylight saving time?
Yes, and it does so for the date you enter rather than for today. Every zone's offset is resolved through the IANA time zone database at the specific instant you are converting, so a meeting on 1 March and the same meeting on 15 March between New York and London will correctly show a five-hour gap and a four-hour gap respectively — the United States moves its clocks forward three weeks before Europe does.
What is an IANA time zone identifier?
It is a name like America/New_York, Europe/London, or Asia/Kolkata drawn from the IANA time zone database, the reference dataset that records not only current offsets but every historical rule change. Identifiers are Area/Location pairs, and they are the only safe way to name a zone in software, because abbreviations like CST are ambiguous — US Central, China Standard, and Cuba Standard all claim it.
Why do some time zones have a 30 or 45 minute offset?
Because zones are political, not geometric. India settled on UTC+05:30 to run a wide country on a single clock. Nepal chose UTC+05:45 to sit fifteen minutes ahead of India. Adelaide is UTC+09:30 and the Chatham Islands are UTC+12:45. Any code that assumes offsets are whole hours will eventually be wrong for around a fifth of the world's population.
What is UTC and how is it different from GMT?
UTC (Coordinated Universal Time) is the atomic-clock standard that every zone is defined as an offset from. GMT (Greenwich Mean Time) is a time zone that happens to equal UTC+00:00 in winter — the United Kingdom moves to BST (UTC+01:00) in summer, so "GMT" and "London time" are not the same thing all year. Store and compare instants in UTC; convert to a zone only for display.
How many time zones are there in the world?
There are 24 one-hour bands in theory, but around 38 distinct UTC offsets are actually in use once half-hour and quarter-hour zones are counted, spanning UTC−12:00 to UTC+14:00. That 26-hour spread is why two places on Earth can be on different calendar dates at the same instant. The IANA database itself defines several hundred named zones, because it tracks historical rules as well as current ones.
What happens to a time that falls in a daylight saving gap?
When clocks spring forward, an hour of local time never exists, so 02:30 on the transition night in New York is not a real reading. The converter resolves such an input to the instant immediately after the transition rather than returning a wrong answer silently. Times in the autumn overlap, where the same wall clock happens twice, resolve to the first occurrence — the convention most calendar software follows.
