Timezone Converter

How does this work?

Pick a reference date and time, and see the equivalent local time across major cities and timezones around the world, calculated using your browser's built-in timezone database.

The IANA time zone database — the actual data quietly behind this tool

Correctly calculating local time across the world requires more than simple, fixed UTC offset math, because a location's actual offset from UTC can genuinely change — some countries adjust for daylight saving, some occasionally change their own official offset entirely, and some have shifted their daylight saving rules over time. This is precisely why every major browser and operating system relies on the IANA Time Zone Database (also informally called "tz data" or "the Olson database" after its original creator), a continuously maintained, meticulously researched reference of every time zone's actual, complete history of offset and daylight saving rule changes, tracked all the way back for many locations. This tool's calculations pull directly from your own browser's own built-in copy of this exact database, which is precisely why they correctly and automatically account for daylight saving time transitions and historical rule changes without needing to hardcode or separately track any of that constantly shifting information itself.

Why a time zone name is fundamentally different from a fixed UTC offset

A genuinely important, easy-to-miss distinction: "America/New_York" and "UTC-5" are not actually the same thing, even though they frequently line up and coincide for stretches of the year. A proper named time zone (following the IANA database's own "Region/City" naming convention) encodes the complete, full set of rules for how that location's offset changes throughout the year — including its specific daylight saving transitions — while a fixed offset like "UTC-5" captures only one single specific instant's offset and simply doesn't shift automatically alongside those rules the way a proper named zone does. This distinction matters enormously in practice: a calendar invite or scheduling system that stores only a fixed UTC offset instead of a proper named time zone can display a genuinely wrong, incorrect local time once a daylight saving transition occurs between the time the event was originally created and when it actually happens — which is exactly why using proper named time zones, not fixed offsets, is the correct, standard practice for storing any future-dated event across systems and time zones.

Why daylight saving time exists, and why so many countries don't actually observe it

Daylight saving time's original rationale was shifting an extra hour of natural daylight into the evening during summer months, historically justified on energy-conservation grounds, though the real-world energy savings have been genuinely debated and questioned by more recent research. Observance today varies considerably and is far from universal — most of Europe and North America observe some form of it, while most equatorial countries don't bother at all, since day length near the equator barely varies across the seasons in the first place, making any daylight-shifting benefit essentially moot there. Even among the countries that do observe daylight saving, the exact specific transition dates differ meaningfully between regions (the US and the EU, for instance, switch on different specific calendar dates from each other), which is exactly the kind of detailed, country-specific rule the IANA database described above exists specifically to track accurately.

Why some time zones sit at genuinely odd 30- or 45-minute offsets

Most of the world's time zones sit at whole-hour offsets from UTC, but a genuine handful of countries deliberately use 30-minute or even 45-minute offsets instead — India (UTC+5:30), Nepal (UTC+5:45), and parts of Australia (UTC+9:30) are commonly cited real examples. These unusual offsets typically reflect a specific country's own considered, deliberate choice to more closely align local clock time with true solar noon for their particular geographic longitude, rather than simply accepting whichever neighboring whole-hour zone happened to be nearby. While these fractional offsets can occasionally complicate meeting scheduling and time-difference math across zones, they're a completely legitimate, officially recognized part of the full time zone system — not any kind of error or unusual edge case — and this tool correctly, automatically handles them exactly the same way it handles any standard whole-hour offset.

Limitations of this tool

This tool calculates equivalent local time across major world cities using your browser's own built-in, continuously updated IANA time zone database — accuracy for daylight saving transitions and historical offset changes genuinely depends on how current that specific browser's own internal copy of the underlying database happens to be, though major browsers do update this data regularly. It shows a curated selection of major, commonly referenced world cities rather than every single one of the many hundreds of individual time zones the full IANA database actually tracks, and it doesn't account for a location's own specific historical calendar system quirks predating standardized modern time zones.