World Clock & Meeting Planner

What is a World Clock & Meeting Planner?#

A world clock shows the current wall-clock time in several cities at once. A meeting planner goes one step further: it lets you pick a reference moment and read off what that same instant looks like in every timezone you care about — so you can find an hour that lands inside everyone’s working day instead of accidentally asking a colleague in Tokyo to take a call at 11 pm.

The reason this is harder than it looks is Daylight Saving Time. A city’s offset from UTC is not a constant: New York is UTC-5 in winter (EST) but UTC-4 in summer (EDT); London is UTC+0 in winter but UTC+1 in summer (BST); Sydney is the mirror image, on summer time during the northern winter. Naive “subtract 8 hours” math produces meetings that are an hour off for half the year. This page computes every offset at the specific instant you are planning for, using the browser’s Intl timezone database, so DST is applied correctly and automatically.

Beyond the clock, the page flags each zone as Work or Off based on working hours you control, so a single glance tells you whether a proposed time is humane for every location.

How to use it#

1. The page boots in Now mode, ticking live, with your local timezone, UTC, and three major hubs (New York, London, Tokyo) pre-selected.
2. Use the Add timezone dropdown to add any of the world’s IANA zones. The list comes from Intl.supportedValuesOf('timeZone') on modern browsers (hundreds of zones), with a curated fallback of roughly 24 common cities on older engines.
3. Switch to Reference mode to plan a meeting: pick a date and time (interpreted in your local zone by default), and every row re-renders to show that same instant in each zone — with the date rolling forward or back across the international date line as needed.
4. Set Work hours (defaults to 9–18) to control which rows are flagged Work versus Off. Rows whose local hour falls inside the window and on a weekday light up; those outside do not.
5. Reset returns to the default zone set; Clear all empties the list.

Key features#

• DST-aware offsets. Every offset is derived from the zone’s wall-clock fields at the chosen instant, not from a fixed table — so a meeting planned in July stays correct when DST rules change, and northern and southern hemisphere zones are handled symmetrically.
• Reference-time planning. Flip to Reference mode, type a local time, and read every other zone’s equivalent at that exact instant. The date input is DST-safe via a two-pass offset refinement that handles transition boundaries correctly.
• Work/Off flagging. Each row is tagged Work or Off based on the local hour and weekday, against working hours you can adjust. Scanning a column of flags is far faster than mentally subtracting offsets.
• Localized weekday and time names. Weekday and month labels come from Intl.DateTimeFormat in the page’s locale — no hand-translated strings to go stale.
• Full IANA zone coverage. Hundreds of zones, including the half-hour and forty-five-minute oddities (India UTC+5:30, Nepal UTC+5:45, parts of Australia UTC+9:30).

Worked example#

You are in Shanghai and need a call with New York, London, Tokyo and Sydney. Switch to Reference mode and enter 2026-08-10 09:00 (a Monday) in Asia/Shanghai. The page resolves that single instant across all five zones:

Asia/Shanghai     UTC+08:00   Mon 09:00   Work
Asia/Tokyo        UTC+09:00   Mon 10:00   Work
Australia/Sydney  UTC+10:00   Mon 11:00   Work
Europe/London     UTC+01:00   Mon 02:00   Off
America/New_York  UTC-04:00   Sun 21:00   Off

August is northern-hemisphere summer, so London is on BST (UTC+1) and New York on EDT (UTC-4); Sydney is in southern winter on AEST (UTC+10, no DST). Shanghai and New York sit 12 hours apart under EDT, so 09:00 Monday in Shanghai is still 21:00 Sunday in New York — notice the date rolling back across the international date line. The Work/Off flags make the verdict obvious: a 09:00 Shanghai slot works for the Asia-Pacific trio but puts London at 02:00 and New York late on Sunday evening — nobody in those cities is awake. Pushing the call to 21:00 Shanghai flips it: 14:00 London and 09:00 New York (both now Work), but 22:00 Tokyo and 23:00 Sydney (now Off). There is no slot inside normal business hours for all five — which is exactly the kind of finding a planner is supposed to surface, so you can negotiate a compromise (a rotating early/late slot) instead of accidentally scheduling someone for midnight.

FAQ#

Why is the offset for my city not a whole number of hours?#

Because not every timezone is offset by a whole hour. India is UTC+5:30, Nepal UTC+5:45, the Northern Territory UTC+9:30, and the Chatham Islands UTC+12:45. This page shows offsets to the minute (UTC+05:30) precisely so those zones are handled correctly — a tool that rounds to whole hours would silently be half an hour wrong for over a billion people.

Do I need to worry about Daylight Saving Time?#

No — the page handles it for you. Every offset is computed at the specific instant shown (Now or your Reference time), using the browser’s timezone database, so DST is applied or not applied exactly as that zone’s rules dictate. A meeting planned in March will still show the correct offsets after the spring-forward, because the tool re-derives them at the instant of the call rather than reading them from a fixed table.

Why do two cities show different dates for the same instant?#

Because of the international date line. At any given moment it is already “tomorrow” in Asia-Pacific while it is still “yesterday” in Hawaii. When you pick a reference time, each row shows the local date alongside the time, so a 22:00 Honolulu slot that is 18:00 the next day in Tokyo is unambiguous — the date column catches what a time-only display would hide.

Can I trust the timezone list to be current?#

On any modern browser (Chrome 99+, current Firefox, Safari, Edge) the list comes from Intl.supportedValuesOf('timeZone'), which mirrors the IANA timezone database the operating system ships. On older engines the page falls back to a curated set of roughly 24 widely-used zones, so the tool still works — just with fewer obscure zones to pick from. The zone rules themselves (DST dates, offsets) come from the same database the browser uses for its own clock.