🕒 Timezone Converter & World Clock

Convert a datetime across multiple IANA timezones (400+) at once. Default view shows Tokyo, NY, LA, London, Paris, Sydney, Mumbai and Sao Paulo. DST handled automatically, UTC offsets shown, live ticking world clock.

100% Free No signup Browser-only 5 languages Dark mode

🔒 About Privacy

・All conversions run entirely in your browser via the Intl.DateTimeFormat API
・The datetime you enter is never sent to any server

Mode

Source timezone

Datetime (custom mode)

Add city Auto-refresh every 1 sec

City / Timezone	Date	Time	UTC offset	DST

📖 Where people get stuck

Line up world clocks for IANA time zones — more than four hundred of them — and convert a given moment into the local time of each city. Daylight saving is handled automatically by Intl.DateTimeFormat, and everything runs in the browser. The times shown are accurate; things break at the point where you store one as an appointment — a time zone is a property of a place, not a fixed offset. That distinction is behind everything below.

Case	What happens	What to do
A recurring meeting shifts by an hour twice a year	Daylight saving transitions fall on different dates in different countries. The United States runs from the second Sunday in March to the first Sunday in November; the EU from the last Sunday in March to the last Sunday in October. Because of that gap, from mid to late March and from late October to early November, the difference between New York and London is four hours rather than the usual five — a window of a few weeks that appears twice a year. Japan has no daylight saving, so pinning the Japanese time moves the other end, and pinning the other end moves Japan. The southern hemisphere inverts it again: Australia starts in October and ends in April.	Write both local times into the invitation — Tokyo 10:00 and New York 21:00 the previous day, side by side, lets the other person notice during the shifted weeks. When you use a calendar invitation, always send it with a time zone: the major calendars store the appointment by IANA name and follow the daylight-saving transitions automatically. What you must not do is fix it by offset — record it as 10:00 at UTC+9 and it moves in the other person calendar at every transition. Getting into the habit of asking once, just after a transition, whether this week is still the right time removes almost all of these incidents.
Assuming every offset is a whole number of hours	Some places use offsets in half hours and quarter hours. India is `+05:30`, Nepal `+05:45`, Iran `+03:30`, Newfoundland `-03:30`, and the Chatham Islands in New Zealand `+12:45`. Write code assuming whole-hour offsets and it is quietly thirty minutes out for exactly those places — and because they rarely appear in a test list, nothing catches it. The size of a daylight-saving shift is not always an hour either: Lord Howe Island in Australia moves by thirty minutes.	Hold offsets in minutes — `+540`, not `+9`. When displaying them, do not write them as decimals: `+05:30` is the correct form, and `+5.75` invites misreading. Better still, do not compute offsets yourself at all: hand an IANA time zone name to `Intl.DateTimeFormat` or your language standard date library and the half-hour offsets, the daylight saving and the rule changes are all handled for you. The urge to write your own time zone arithmetic is itself a warning sign — there are too many exceptions for almost anyone to get it right.
Time zone abbreviations do not identify a zone	Three-letter abbreviations are not unique. `CST` can mean US Central Standard Time (UTC-6), China Standard Time (UTC+8) or Cuba Standard Time (UTC-5). `IST` is India (UTC+5:30), Ireland (UTC+1) or Israel (UTC+2). And the abbreviation itself changes with daylight saving: the US east coast is `EST` in winter and `EDT` in summer, so an appointment written as 9am EST on a summer date is internally contradictory. Use abbreviations in international correspondence and the other person may read a different time, and neither of you is wrong.	Use IANA names for storage and for communication — `Asia/Tokyo`, `America/New_York` — because they are unique and carry the daylight-saving rules and the historical changes with them. Reserve abbreviations for display to humans, and even then pair them with a city name, as in Tokyo time (JST). In prose, writing the place, date, time and offset together — 5 October, 10:00 Japan time (UTC+9) — leaves the least room for misreading. When you do not know where the other person is, write it in UTC: it is equidistant from everyone, it costs them a conversion, and it costs nobody a misunderstanding.

The time zone database (tzdata) is updated several times a year. Countries continue to adopt, abolish and reschedule daylight saving: Mexico abolished it across almost the whole country in 2022, Jordan and Syria moved to summer time permanently, and the EU has been debating abolition for years. In other words, time zone rules are data, not code, and that data goes stale — pin a container image or an OS version and one day the times for a particular region quietly start being an hour out. Refreshing base images matters for this reason as much as for security. As an operating principle: store what has already happened in UTC, because it is an instant; store future appointments as an IANA time zone name plus a local time, because they are a promise. There is no value in an IANA name on a log timestamp, and conversely storing next year meeting as a UTC instant means it stops being 10am locally the moment the law changes.

📖 How to Use

1

Choose a mode

In "Current time" mode the world clock ticks every second. In "Convert specific datetime" mode the entered datetime is shown in each city local time.
2

Add or remove cities

Pick from 400+ IANA timezones to add cities. Use the X button to remove, or Reset to restore the default 8 cities.
3

Check DST and UTC offset

Each row shows the current UTC offset and whether DST is in effect. Useful for meeting scheduling and server log correlation.

❓ Frequently Asked Questions

What is an IANA timezone?

The IANA Time Zone Database (tz database) defines world timezones using identifiers like Asia/Tokyo and America/New_York. It is the standard used by Linux, macOS, Java, JavaScript and many other systems.

Is DST handled automatically?

Yes. We use the browser Intl.DateTimeFormat API, which applies each timezone DST start and end dates to compute the correct offset.

Is the datetime sent to your server?

No. All conversion and rendering happen entirely in browser JavaScript. No network requests are made.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.