Compare current times across multiple time zones. Click any slot to inspect a specific moment. DST shown automatically. Up to 6 columns.
Intl.DateTimeFormat API. No setting needed.Asia/Tokyo). You can add up to 5 additional columns — 6 total.UTC (Coordinated Universal Time) is the global time standard maintained by atomic clocks. It does not observe Daylight Saving Time and never changes — it is the fixed anchor from which all local times are derived.
UTC offsets
Local time zones are expressed as UTC+N or UTC−N. Tokyo is UTC+9: when UTC is 12:00, Tokyo is 21:00. New York is UTC−5 in winter: when UTC is 12:00, New York is 07:00. The "offset" is the number of hours (and sometimes minutes) added to or subtracted from UTC.
Why UTC does not change for DST
UTC is the reference point, not a local time zone. When New York "springs forward" to EDT, the offset changes from UTC−5 to UTC−4 — but UTC itself stays the same. This is why developers store timestamps in UTC and convert to local time only for display. A UTC timestamp is unambiguous; a local timestamp is not.
GMT vs UTC
GMT (Greenwich Mean Time) and UTC are functionally identical for timekeeping purposes — they share the same current time, differing by at most 0.9 seconds (corrected by occasional leap seconds in UTC). The practical difference: GMT is a timezone used in the UK during winter; UTC is the international standard used by computers, aviation, and telecoms. In everyday scheduling, treat them as equivalent.
A UTC offset like UTC-5 tells you the current difference from UTC. An IANA identifier like America/New_York tells you the full rule set — including when and by how much the offset changes. For scheduling, the IANA identifier is always correct; the offset alone is not.
| UTC offset (e.g. UTC-5) | IANA identifier (e.g. America/New_York) | |
|---|---|---|
| Changes with DST? | No — fixed | Yes — tracks DST transitions automatically |
| Unique per location? | No — many cities share the same offset | Yes — each zone has its own rule history |
| Safe for future scheduling? | Only until the next DST change | Yes — applies correct future rules |
| Maintained by | Ad-hoc / whoever wrote the code | IANA — updated several times per year by governments |
| Example | UTC-5 (could be EST, COT, PET, ECT…) | America/New_York, America/Bogota, America/Lima — distinguishable |
Most time zones differ from UTC by whole hours, but eight populated zones use 30-minute or 45-minute offsets. This tool uses 30-minute time slots so these zones display correctly aligned against whole-hour columns — a 5:30 PM slot in Mumbai corresponds to the exact same UTC moment as any other column.
| City | IANA identifier | UTC offset | Note |
|---|---|---|---|
| Kathmandu | Asia/Kathmandu | UTC+5:45 | Only +45 min offset in the world |
| Mumbai / Delhi | Asia/Kolkata | UTC+5:30 | No DST; permanent standard time |
| Colombo | Asia/Colombo | UTC+5:30 | Same offset as IST, separate political zone |
| Yangon | Asia/Yangon | UTC+6:30 | Myanmar — abandoned DST in 1942 |
| Tehran | Asia/Tehran | UTC+3:30 / +4:30 | Observes DST — switches at Iranian calendar equinox |
| Kabul | Asia/Kabul | UTC+4:30 | No DST; Afghanistan — half-hour ahead of GST |
| Darwin | Australia/Darwin | UTC+9:30 | No DST; Northern Territory |
| Adelaide | Australia/Adelaide | UTC+9:30 / +10:30 | Observes DST in southern-hemisphere summer (Oct–Apr) |
Each mistake below has caused real missed meetings. Understanding the root cause makes the fix obvious.
1. Saving a UTC offset instead of an IANA identifiermost common
Meeting at 3 PM UTC-5Meeting at 3 PM America/New_York (EST in winter, EDT in summer)UTC-5 is ambiguous — it refers to Eastern Standard Time in winter but not summer, when New York shifts to UTC-4 (EDT). An IANA identifier like America/New_York captures the full DST schedule. Code that stores "-05:00" will silently schedule meetings an hour off for half the year.
2. Assuming same UTC offset = same timezone
Lima and New York are both UTC-5, so they matchLima is UTC-5 permanently; New York is UTC-5 only in winterPeru (America/Lima) does not observe DST and stays at UTC-5 year-round. In summer, New York shifts to UTC-4. A meeting scheduled assuming they match will be 1 hour off for roughly 7 months of the year.
3. Forgetting that DST switches happen on different dates in each hemisphere
"Clocks go back" in October — correct for both hemispheresNorthern hemisphere: spring forward Mar/Apr, fall back Oct/Nov. Southern hemisphere: the opposite.Australia, New Zealand, and South Africa observe DST in the opposite direction — their clocks go forward in October and back in April. A team split between London and Sydney may find their overlap window shifts by up to two hours during the transition weeks in March and October when both hemispheres are adjusting simultaneously.
4. Ignoring the International Date Line when scheduling across the Pacific
Scheduling a 9 AM Tuesday meeting in San Francisco for the Tokyo team9 AM Tuesday San Francisco = 2 AM Wednesday TokyoSan Francisco (America/Los_Angeles) is UTC-8 in winter; Tokyo (Asia/Tokyo) is UTC+9 — a 17-hour difference that crosses midnight. Tuesday morning in California is Wednesday early morning in Japan. Use a visual timeline (like the 24-hour slot view in this tool) to see date boundaries before confirming.
UTC (Coordinated Universal Time) is the primary time standard by which the world regulates clocks and time. It is defined by atomic clocks and kept within 0.9 seconds of UT1 (solar time) using occasional leap seconds. UTC does not observe Daylight Saving Time and does not change with the seasons — it is the fixed reference point from which all local time zones are expressed as positive or negative offsets. UTC replaced GMT as the international standard in 1972; the two are functionally identical for most purposes.
UTC-5 is a fixed numerical offset — it means "5 hours behind UTC" at all times, year-round. America/New_York is an IANA timezone identifier that describes a full set of rules: UTC-5 in winter (Eastern Standard Time, EST) and UTC-4 in summer (Eastern Daylight Time, EDT). If you store UTC-5 in a calendar system, meetings will be scheduled 1 hour early for roughly half the year. Always use IANA identifiers — they capture the complete DST schedule, not just the current offset.
The IANA Time Zone Database (also called tz or zoneinfo) is a collaborative compilation of historical local time data for locations around the world, maintained under the auspices of IANA (Internet Assigned Numbers Authority) and edited by Paul Eggert since 2005. It is updated several times per year to reflect changes by governments to DST rules, UTC offsets, and zone boundaries. Every major operating system, programming language, and browser ships the IANA database — when your device displays the correct local time after a DST change, it is reading from a recently updated copy of this database.
DST detection works by comparing the UTC offset of a timezone on 15 January against 15 July of the current year. If the two offsets differ, the timezone observes DST. The currently active offset is then compared to the lower of the two (the standard-time offset) — if it is greater, DST is active. This works for both northern-hemisphere zones (which shift forward in spring) and southern-hemisphere zones (which shift forward in autumn), because the comparison is purely offset-based with no assumption about which hemisphere applies.
Most timezones are separated by whole hours, but several are offset by 30 or even 45 minutes from UTC. Kathmandu (Asia/Kathmandu) is UTC+5:45, India and Sri Lanka (Asia/Kolkata, Asia/Colombo) are UTC+5:30, Iran (Asia/Tehran) alternates between UTC+3:30 and UTC+4:30, and northern Australia (Australia/Darwin, Australia/Adelaide) uses UTC+9:30. A 30-minute slot granularity means these zones display correctly aligned against whole-hour zones — a 5:30 PM slot in Mumbai lines up with the same UTC moment as any other column.
There is no universal 'golden hour' — it depends on which cities are involved. A practical starting point: New York (UTC-5/-4) and London (UTC+0/+1) overlap from 2–5 PM London / 9 AM–12 PM New York. Adding Singapore (UTC+8) to that combination leaves almost no overlap during normal hours — Singapore's 9 AM is London's 1 AM. For US–Europe–Asia teams, async communication is typically more practical than a single shared meeting slot. Use the 24-hour view in this tool to drag across time slots and visually identify workday overlap across all three zones.
Yes. The DST indicator and UTC offset shown in each column are derived from the browser's Intl.DateTimeFormat API, which reads IANA timezone data from the operating system. When your OS updates its timezone database (which happens automatically on most devices), the correct DST schedule is applied immediately — no manual update is needed. The live clock refreshes every second, so the offset label and DST badge reflect the accurate current state at all times.
Add the relevant timezones as columns, then scroll the time grid until you see workday hours (highlighted in the green work zone) overlapping across all columns at the same slot. Click a slot to pin it — all columns lock to that moment and show the corresponding local time, date, and day of week. If no slot shows working hours in all zones, shift the date by a day: some Asia–Americas combinations have better overlap on one weekday than another due to the date boundary crossing.