Time Zones Calculator

Time Zones Calculator: convert time zones instantly. Full formula, unit table, and worked example.

The Time Zone Converter simultaneously displays a chosen time across 20 major cities worldwide — from London to Auckland — using DST-aware IANA timezone identifiers via the browser's native Intl.DateTimeFormat API. Cities are colour-coded by work hours (green), sleep hours (grey), and highlighted in blue for the source city. Use Length Conversion Calculator for scheduling across global teams, or Weight Conversion Calculator to plan travel timings accurately.

The IANA timezone database (the "tz database" or "Olson database") is used by all major operating systems, browsers, and programming languages as the authoritative source of timezone rules, including Daylight Saving Time transitions. DST currently affects approximately 70 countries — the EU voted to abolish seasonal clock changes in 2019, but implementation has been delayed indefinitely. The optimal global meeting window that covers both New York (EST/EDT) and Europe without early/late strain is approximately 14:00–16:00 UTC. For meetings spanning the US West Coast, Europe, and India, no single time works within 9am–6pm for all participants — a rotation of the "unsociable" slot is the fairest approach.

Select your Source city from the dropdown — this is the city whose local time you are entering.
Enter the Hour (0–23) in 24-hour format — e.g., 14 for 2pm.
Enter the Minute (0–59).
The grid instantly shows the equivalent local time in all 20 cities — green background means it's business hours (9am–6pm); grey means the city is likely asleep.
Use the Reset button to return to 09:00 London time as the default.

How time zone conversion works

The converter uses JavaScript's Intl.DateTimeFormat API with IANA timezone identifiers (e.g., "America/New_York", "Asia/Tokyo"). The browser calculates each city's UTC offset automatically, including DST transitions, so you never need to manually apply +/− offsets.

The algorithm works as: (1) Calculate the UTC offset of the source city at the selected time by comparing the input time to what the source formatter produces for a reference UTC datetime. (2) Adjust the reference UTC datetime by the offset difference. (3) Format the adjusted UTC datetime using each city's timezone for the display.

Example: It is 14:00 in London (BST, UTC+1). New York is at UTC−4 (EDT). UTC time = 14:00 − 1h = 13:00 UTC. New York = 13:00 UTC − 4h = 09:00 EDT. This makes London at 2pm the perfect time to call New York at 9am start of business.

Reading the time zone grid

Work hours, sleep hours, and source city highlight

The colour system: Blue border = your source city. Green background = business hours (9am–6pm local time) — a good time to call. Dimmed grey = likely sleeping (before 7am or after 11pm). White background = evening, acceptable for urgent calls. Use this visual system to identify the "green zone" for a meeting time that works for multiple participants without unsociable hours.

The timezone abbreviation shown (e.g., BST, EDT, IST) reflects the current DST-adjusted timezone name, not just the standard UTC offset. This is critical: New York is UTC−5 (EST) in winter but UTC−4 (EDT) in summer, and the UK is UTC+0 (GMT) in winter but UTC+1 (BST) in summer. The Intl API handles this automatically.

Conversion tips and best practices

Optimal US-to-UK call window: 14:00–17:00 London / 9:00–12:00 New York EST (or 15:00–18:00 London / 10:00–13:00 EDT in summer). This is the "golden hour" for transatlantic calls.
For APAC + Europe overlap: there is typically no overlap during business hours — the closest is early morning Europe (7:00–9:00 CET) with late afternoon Singapore (14:00–16:00 SGT).
India (IST, UTC+5:30) is always 5.5 hours ahead of London — it never changes for DST, making it the most consistent timezone for international scheduling.
For recurring global meetings, use a rotation system where the unsociable slot (early morning or late evening) is shared fairly across participants in different regions.
China (CST, UTC+8) does not observe DST — while the US and EU clock changes shift the gap between them and Beijing by 1 hour twice per year.
Use ISO 8601 format (e.g., "2024-05-15T14:00Z") when communicating meeting times across timezones in writing — it's unambiguous and timezone-aware.

IANA timezone database: used by all major operating systems, browsers, and programming languages — updated approximately 5 times per year for DST rule changes. [IANA.org]
Countries observing DST: approximately 70, down from over 100 in the 1980s as many countries (notably in Asia and Africa) have permanently abandoned the practice. [timeanddate.com]
EU DST abolition vote: the European Parliament voted 410–192 to abolish seasonal clock changes in 2019, but implementation has been indefinitely delayed due to lack of member state agreement on permanent timezone. [European Parliament, 2019]
Optimal global meeting window covering US East, Europe, and India morning: 14:00–16:00 UTC (10am EDT / 3pm BST / 7:30pm IST). [Google Calendar scheduling data]

Common mistakes to avoid

Adding/subtracting fixed UTC offsets without accounting for DST — New York's offset is −5 in winter and −4 in summer; using −5 year-round causes 1-hour errors for 6 months.
Confusing the date when crossing midnight — a 23:00 meeting in London is 06:00 the next day in Tokyo; always confirm the date as well as the time for Pacific/Asia calls.
Assuming India (IST) changes clocks — IST is always UTC+5:30 with no DST. Many scheduling tools get confused by the 30-minute offset.
Using local timezone abbreviations without UTC offset — "CST" refers to Central Standard Time (UTC−6, US), China Standard Time (UTC+8), and Cuba Standard Time (UTC−5). Always use IANA names or UTC offsets for unambiguous scheduling.

Time zone data is sourced from the IANA timezone database, which is maintained as a public resource. DST rules and timezone offsets change periodically via government legislation. This calculator provides general information only and is intended for scheduling and planning purposes. For legal or contractual time-sensitive matters, always verify the applicable timezone rules with the relevant jurisdiction's official authority.