World Clock & Meeting Planner

Live clocks for cities worldwide. Click any cell in the meeting slider to find the best time for everyone.

{{ opt.label }}
{{ __t('no_matches') }}
{{ tzShortName(c.tz) }} · UTC{{ utcOffsetLabel(c.tz) }} · {{ diffToHome(c.tz) }} {{ __t('vs_home') }}
{{ __t('empty_hint') }}

{{ __t('meeting_heading') }}

{{ __t('work_hours') }}: –
{{ c.label }}
{{ __t('legend_work') }} {{ __t('legend_late') }} {{ __t('legend_sleep') }} {{ __t('legend_selected') }}

What is the world clock for?

  • Remote teams — see at a glance whether colleagues in NYC are still reachable
  • Travel — plan jet lag, book flights
  • Meetings — find overlapping work hours, schedule calls
  • Calls — avoid waking anyone at 3 AM
  • Software releases — coordinate deploy windows

Meeting slider — how does it work?

Each row is a 24-hour scale for one time zone. Green cells mark the working hours (default 9 AM–5 PM, configurable in the header). Orange marks edge hours (~2 h before/after), grey is off-hours. When green stacks vertically across all rows, it's a good meeting slot.

Click any cell to highlight that hour across all rows. The +1 / −1 indicator shows when a cell already belongs to the next/previous calendar day. DST transitions are handled automatically.

100% offline & no tracking

The world clock runs entirely in your browser. No data is sent to servers, no tracking, no cookies (only localStorage for your chosen cities). Time calculations use the native Intl.DateTimeFormat API, which correctly handles every IANA time zone including DST rules.

Time zones: wall clock, UTC, and IANA

A time zone is much more than "UTC plus X hours". It is a rule for mapping the absolute time line (UTC) onto a local wall-clock display — including every historical change, DST transition, and political shift. The IANA time-zone database (also "Olson database" or just "tzdata") has collected these rules since 1986 and is updated several times per year; the Europe/Berlin entry, for instance, contains DST transitions from the German Empire in 1916, the second summer time of 1980, and the post-1990 unification with the former East. Browsers and operating systems hook into this database directly — calling Intl.DateTimeFormat('en-US', {timeZone: 'Asia/Kolkata'}) returns the correct current Indian time (UTC+5:30) without you having to maintain any rules yourself.

EU summer time is governed by Directive 2000/84/EC: on the last Sunday in March, clocks move forward one hour at 01:00 UTC (in Germany 02:00 → 03:00), and on the last Sunday in October they move back at 01:00 UTC (03:00 → 02:00). These days are asymmetric — on the spring Sunday one hour is skipped entirely; on the autumn Sunday, local 02:00 to 03:00 occurs twice. The proposal to abolish DST (EU 2018/921) has been frozen for years. Outside Europe the picture is more varied: Russia, China, India, Japan, and Argentina do not switch at all; in Australia only some states do; the US has switched on the second Sunday in March and first Sunday in November since 2007.

Some zones have offsets that surprise many travellers: India is at UTC+5:30, Nepal at UTC+5:45, Iran at UTC+3:30 (in winter), Newfoundland at UTC−3:30, the Chatham Islands at UTC+12:45. Large countries often span several zones — the US has six (Eastern, Central, Mountain, Pacific, Alaska, Hawaii), Russia eleven, while China officially uses only one (Asia/Shanghai) despite geographically covering five. This world clock reads the current DST rule directly from the browser's tzdata store and therefore adapts automatically to political changes (such as Mexico's 2022 vote) as soon as the browser receives an update.

Conversion and offset math

A local time in a zone is always mediated by UTC: local = UTC + offset(tz, date). The offset is date-dependent because DST raises (in Europe) or lowers (Southern Hemisphere) the summer value by one hour. Example: 9 June 2026 12:00 UTC is 14:00 in Berlin (CEST = UTC+2) and 21:00 in Tokyo (JST = UTC+9). In winter Berlin switches to CET = UTC+1, so the same UTC moment shows as 13:00 Berlin time. For meeting planning, first convert every participant to UTC, then find the common window. Difference between two zones: Δ = offset(tz_a) − offset(tz_b). Tokyo − Berlin in summer = 9 − 2 = 7 hours; in winter = 9 − 1 = 8 hours.

Practical examples

Real constellations for distributed teams:

  • Berlin 09:00 (CEST) = New York 03:00 (EDT) = Tokyo 16:00 (JST) = San Francisco 00:00 (PDT) — summer offsets with DST.
  • Mumbai 14:30 (IST = UTC+5:30) = London 09:00 (BST = UTC+1) = New York 04:00 (EDT) = Sydney 19:00 (AEST = UTC+10).
  • Common Berlin/New York meeting window: 15:00–18:00 Berlin (= 09:00–12:00 New York) is the only block where both sites are within normal working hours.
  • Date line: when Apia (Samoa) shows Friday 23:00, Pago Pago (American Samoa) is still Thursday 23:00 — same longitude, 24 hours of date difference.
  • EU DST changes in 2026: 29 March 02:00 → 03:00 (forward +1 h), 25 October 03:00 → 02:00 (back −1 h). Tokyo–Berlin gap swings from 8 h to 7 h and back.

Limits and pitfalls

Be careful at DST transitions: a local time like 2026-10-25 02:30 Berlin is ambiguous — it occurs twice, once as CEST and once as CET. Booking systems typically pick the first instance or store UTC directly. Also: the browser's tzdata is only as current as the browser itself. To correctly display a recently changed zone (Iran 2022, Mexico 2022, Morocco 2018), keep the operating system up to date. The Y2038 boundary does not affect the browser directly (JavaScript uses double-precision milliseconds) but it does affect old embedded systems. Leap seconds are ignored here — this clock is not built for second-accurate satellite tracking. For UI purposes (meetings, travel, log correlation) it is entirely sufficient.

Frequently asked questions

Does the clock update automatically at DST changes?
Yes. The display uses Intl.DateTimeFormat with the zone as parameter — the browser knows the DST rule from tzdata and jumps automatically at the transition. You do not have to adjust anything.
Why does the city sometimes show +1 day or −1 day?
Because the remote city's local time falls on a different calendar day than the home time. When it is Monday 23:00 in Berlin, Sydney is already Tuesday 08:00 (+1 day) and Los Angeles is still Monday 14:00.
What do the colours in the meeting slider mean?
Green = within the configured work hours, orange = fringe time (two hours before, four hours after), blue-grey = sleep window. This lets you spot the common slot for all sites at a glance.
Can I share my list?
Yes — the "Copy share link" button generates a URL containing the zones, home, work hours, and selected slot. Anyone opening the link sees your exact configuration in their current live time.
Which zones are supported?
Every IANA zone the browser knows — currently around 400 plus their aliases. In city mode we ship 150+ preselected major cities with flag and country code for fast pick.
Is there a 12-hour mode?
The digital clock currently shows 24-hour format; the analog face is of course 12-hour. The date display (weekday and date) follows your browser locale.

Related tools