World Timezone Clock

Working Across Timezones Without Losing Sleep

Distributed teams, async-friendly companies, and globally-deployed software all run into the same problem: time is a mess. UTC is the only sane reference; everything else is a political layer over solar geometry. This tool gives you a fast view of "what time is it for everyone right now," plus the overlap visualization that answers "when can we all meet."

The Core Concepts

UTC: The Reference

Coordinated Universal Time is the global time standard. Atomic clocks, leap seconds, no DST. Everything else is described as an offset from UTC.

The date line zigzags around political boundaries. Samoa is UTC+13/+14; American Samoa next door is UTC-11. They're a few miles apart but 24 hours different.

Timezone names (IANA / tz database)

The authoritative database is IANA tzdata (formerly Olson DB): America/New_York, Europe/London, Asia/Kolkata. Names use Continent/City format, with the city chosen as a canonical representative. The DB tracks every historical timezone change, useful for converting past timestamps.

Avoid old short names (EST, PST), they're ambiguous (CST = US Central Standard or China Standard?) and don't capture DST. Use IANA names.

Offsets vs timezones

UTC+5 is an OFFSET. America/New_York is a TIMEZONE. The same timezone can have different offsets across the year (DST). Always use timezone NAMES for recurring events; OFFSETS for one-shot timestamps.

Daylight Saving Time

DST shifts the local clock forward an hour in spring and back an hour in autumn, to give "more evening daylight" during summer months. The transitions:

• US/Canada: 2nd Sunday of March → 1st Sunday of November. (Hawaii, most of Arizona don't observe.)
• EU: last Sunday of March → last Sunday of October. (Being phased out, debate ongoing as of 2026.)
• Australia: 1st Sunday of October → 1st Sunday of April (Southern Hemisphere reversed seasons; states vary).
• UK: same as EU.
• Brazil: dropped DST in 2019.
• Russia, China, India, Japan: no DST.
• Most of Africa, the Middle East: no DST (some exceptions like Iran, Morocco).

Edge cases

• Spring forward: clocks jump from 1:59 to 3:00. The 2:00–2:59 hour doesn't exist that day.
• Fall back: clocks jump from 1:59 to 1:00. The 1:00–1:59 hour happens twice. Timestamps without UTC offset are ambiguous.

Software bugs cluster around these dates. Test your scheduling code on the actual transition days.

Working in Distributed Teams

The "follow the sun" myth

In theory, three teams 8 hours apart can hand off work continuously. In practice, the handoff overhead (context, code review, blocking decisions) often makes it slower than one team. Most successful distributed teams pick timezone overlap windows rather than full handoff.

Finding overlap

Two engineers, one in SF (PST) and one in Berlin (CET). The offset is 9 hours.

• SF 9am = Berlin 6pm. (SF morning meeting is end-of-day for Berlin.)
• SF 8am = Berlin 5pm. (Latest sane meeting for Berlin.)
• SF 5pm = Berlin 2am. (No.)
• Berlin 9am = SF 12am. (No.)
• Berlin 5pm = SF 8am. (Best overlap.)

The overlap window for both to be "in business hours" is approximately 8–9 AM PST / 5–6 PM CET. One hour. The tool's overlap visualizer makes this immediate.

Adding a third person in Bangalore (IST, UTC+5:30): SF 8am = Berlin 5pm = Bangalore 9:30pm. The Bangalore engineer is missing dinner. Three-way overlap doesn't exist for SF/Berlin/Bangalore in normal hours. Either someone takes the off-hour, or use async communication.

Scheduling rules

• Always confirm timezones in meeting invites. "9am" alone is ambiguous.
• Use named timezones for recurring (Calendar systems handle DST).
• Prefer fewer, denser meetings when timezones don't align, async work fills the rest.
• Rotate the inconvenience: if someone always takes the bad time, they'll burn out.

The JavaScript Side

Getting the user's timezone

Formatting a date in a specific timezone

Computing offset for a given date

JS Date doesn't have a clean "what's the offset for NYC on a given date?" method. Either use Luxon / date-fns-tz / Temporal (Stage 3 as of 2026), or compute via formatted parts.

The Temporal API

The future. Stage 3 proposal, polyfill available, ships in browsers gradually:

Replaces Date for everything. Stronger types, better DST handling, immutable. Use a polyfill for now; transition when browser support is broad.

Common Anti-Patterns

Storing local time strings without offset

event_time = "2026-05-16 15:00", at which timezone? Bug magnet.

Fix: store UTC + display in local, OR local time + named timezone.

Hardcoded offset

if (tz === "PST") return utc - 8, wrong half the year (PDT vs PST).

Fix: use IANA timezones; let the tz library compute.

Using `new Date()` for date arithmetic across DST

Adding 24 hours to a date might give the same wall-clock hour the next day, OR an hour off (across DST transition). Use date-aware libraries.

Ignoring half-hour and 45-minute offsets

India is UTC+5:30. Nepal is UTC+5:45. Don't write offset_hours as an integer.

Sending timestamps without offsets to clients

If the server sends "2026-05-16 14:00:00" and lets the client guess, half your users will see the wrong time. Always include offset (Z for UTC).

Tools for Time Math

Why moment.js is deprecated

Mutable, large, no tree-shaking, replaced by lighter alternatives. Existing code can stay; new code should use date-fns / Luxon / Temporal.

Privacy

The clock uses Intl.DateTimeFormat (browser API, no network) plus local time tick (setInterval). Your selected cities save to localStorage keyed to your browser; nothing leaves the page. Open DevTools Network during use: zero outbound requests. Timezone selections aren't typically sensitive, but they do reveal something about your work patterns and contacts; keeping them local matches the rest of the site.