Scheduling a call across continents — confirming what "3pm CET" is in your colleague's zone. Reading a log timestamp recorded in UTC and translating it to local time for a user-facing report. Checking whether a deploy window or maintenance slot crosses a DST boundary. Sanity-checking that a cron expression in America/New_York fires at the moment you expect from your own zone. Working out the day-of-week change when crossing the international date line.

DST transitions create ambiguous and missing times. When a clock falls back, 02:30 happens twice; when it springs forward, 02:30 doesn't exist at all. The tool picks the standard-time interpretation by default; if you need the other side, shift by an hour either way. Offsets aren't constants. "CET" is UTC+1 in winter and UTC+2 in summer (CEST). The output always shows the actual offset for the date you entered, so trust the displayed offset over the abbreviation. Country abbreviations are not zones. "EST" is ambiguous (US vs Australian); "IST" can mean Indian, Irish, or Israeli. Always pick the IANA zone, not the abbreviation. Historical accuracy is good for the modern era but breaks down for very old dates. Pre-1970 timestamps may use approximated offsets in some browsers. Storing dates: always use UTC. Convert at display time. The UTC line in the output gives you the canonical value to write to your database.

Time Zone Converter

Convert a date and time between IANA time zones. See offsets, DST status, and weekday for both ends.

Date & time (in source zone)

From (source zone)

To (target zone)

Result

Enter input above to see the result.

What is this for?

Time zones are deceptively annoying. A meeting at "9am" means different absolute moments in London, Bratislava, and New York — and the offset between any two of them changes twice a year because of daylight saving, on different dates. This tool takes a wall-clock time in one IANA zone and tells you the exact equivalent in another, with current offsets, the UTC instant, and the day-of-week for both ends.

When to use it

Scheduling a call across continents — confirming what "3pm CET" is in your colleague's zone.
Reading a log timestamp recorded in UTC and translating it to local time for a user-facing report.
Checking whether a deploy window or maintenance slot crosses a DST boundary.
Sanity-checking that a cron expression in America/New_York fires at the moment you expect from your own zone.
Working out the day-of-week change when crossing the international date line.

Why IANA zones (not "GMT+2")

An IANA zone like Europe/Bratislava or America/New_York encodes the historical and ongoing rules for that location — DST start and end dates, time-zone changes (Russia abolished DST in 2014; Türkiye dropped DST in 2016), even Samoa skipping a whole day in 2011. A bare offset like "GMT+2" tells you nothing about whether DST applies, what the rule was last year, or what it'll be next year. Browsers ship the IANA database (via ICU/CLDR) and update it automatically, so the conversion stays correct over time.

Common gotchas

DST transitions create ambiguous and missing times. When a clock falls back, 02:30 happens twice; when it springs forward, 02:30 doesn't exist at all. The tool picks the standard-time interpretation by default; if you need the other side, shift by an hour either way.
Offsets aren't constants. "CET" is UTC+1 in winter and UTC+2 in summer (CEST). The output always shows the actual offset for the date you entered, so trust the displayed offset over the abbreviation.
Country abbreviations are not zones. "EST" is ambiguous (US vs Australian); "IST" can mean Indian, Irish, or Israeli. Always pick the IANA zone, not the abbreviation.
Historical accuracy is good for the modern era but breaks down for very old dates. Pre-1970 timestamps may use approximated offsets in some browsers.
Storing dates: always use UTC. Convert at display time. The UTC line in the output gives you the canonical value to write to your database.