Date & Time

Timezone Converter

Converts a list of times between two IANA zones, applying daylight saving as it stood on each date.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste the times, one per line, as they read in the source zone.
  2. Set the From and To zones. Any IANA name works, not only the ones listed.
  3. Select Convert.
  4. Read the Date column before you send an invitation — a time that lands on the previous or next day is the mistake worth catching.

What timezone converter does

Timezone conversion is only easy if you ignore daylight saving, and ignoring daylight saving is how a meeting ends up an hour out for three weeks each spring. This page takes the offset from your browser’s own IANA database at the instant in question, so a March date and a July date between London and New York give different answers — because they genuinely are different.

Two things get called out explicitly. The first is the day change: a call at 23:30 in Kolkata is the same day in Los Angeles but a 09:45 morning, and the column says so rather than leaving you to notice. The second is the offset gap itself, which is what you actually need when working out whether a window overlaps a working day at the other end.

Frequently asked questions

Yes, and correctly for the date in question rather than for today. The offset comes from your browser’s IANA database at each instant, so the same 09:00 London time converts differently in March and in July — because it genuinely does.

Yes. Any IANA name your browser knows works — Pacific/Auckland, Africa/Lagos, America/Sao_Paulo. The list is short because a dropdown of six hundred names is worse than a text field, not because the rest are unsupported.

A wall clock time in the hour that a spring change removes does not exist, and the conversion settles on the instant either side of the gap. If a result looks an hour out around a change date, that is what happened — and it is a good reason to store timestamps in UTC rather than local time.

Because abbreviations are ambiguous and static. IST is India, Ireland and Israel; EST does not become EDT when the clocks change. America/New_York names a set of rules over time, which is what you actually need, and it stays correct when a government changes those rules.