So funktioniert die Berechnung
Each line in the box is an IANA zone name. For every zone the tool asks the browser's Intl.DateTimeFormat what the local time is right now, derives that zone's offset in minutes, and projects each local working hour to UTC as ((h − offset ÷ 60) mod 24). The overlap is the set of UTC hours every listed zone marks, and it is those UTC hours — not local ones — that the headline count and the coloured band report.
Work start hour and Work end hour are whole numbers in 24-hour form, defaulting to 9 and 17, and the window is half-open: 9 to 17 covers 09:00 through 16:59, eight hours. Widening by one hour at each end often rescues a dead result. Only the first eight lines are used, and the shipped list — Los Angeles, New York, London, Berlin, Singapore, Sydney — leaves no shared hour at all, which is a fair demonstration of the problem.
Two things to know. Offsets are read for today only, so a meeting scheduled across a daylight-saving changeover will drift by an hour and needs rechecking nearer the date. And zones are bucketed into whole UTC hours by rounding down, so half-hour and forty-five-minute offsets such as Asia/Kolkata, Australia/Adelaide and Asia/Kathmandu land up to fifty-nine minutes early. A misspelled zone name is skipped silently rather than flagged.
FAQ
Why does it show zero overlapping hours? +
Because at least one pair of zones shares no working hour. The default list, spanning Los Angeles to Sydney, does exactly that. Widen the start and end hours, or remove the most distant zone, and a shared window usually appears straight away.
What format do the time zone names need? +
IANA identifiers in Area/City form, one per line — America/New_York, Europe/Berlin, Asia/Singapore. Abbreviations such as EST or PST are not accepted, and any name the browser fails to recognise is dropped from the list without showing an error.
Does this handle daylight saving time? +
For today, yes. Offsets come from the browser's timezone database at the moment the page loads, so the current DST state is correct for every zone. A meeting booked across a spring or autumn changeover will shift by an hour.
How do I find a meeting time across the US, Europe and Asia? +
Look for the hour where the band lights up for every zone. With the US West Coast and Asia in the same list that usually means somebody works early or late, so deliberately widen one team's hours rather than hunting for a window that does not exist.
Why is the overlap given in UTC rather than my local time? +
UTC is the only clock every listed zone shares, so it is the unambiguous way to name a common hour. Convert it once to each person's local time when you send the invitation, and calendar software will handle that step for you.
