Each row is one city's local time across the reference date. The highlighted column is the hour everyone's working hours overlap.
Add New York and London, both at the default 9:00–17:00 working hours, and the tool finds the overlap by checking every hour of the day in UTC and asking whether it falls inside every added city's working hours at once. For these two on a recent daylight-saving date, that comes out to a single three-hour window: 9:00 AM–12:00 PM in New York is exactly 2:00 PM–5:00 PM in London. Add a third city on the opposite side of the world with the same standard hours — somewhere around UTC+8, for instance — and that same search can come back empty: a standard 9-to-5 in East Asia simply doesn't share any hour with a standard 9-to-5 on the U.S. East Coast, which is a genuinely common real scheduling problem for globally distributed teams, not a tool limitation.
Time zone offsets change with daylight saving, and not every country switches on the same date — some don't observe it at all. Picking a specific reference date rather than assuming "today's" offset is what lets the timeline stay accurate across the handful of weeks each year when, say, the US and UK are on different sides of their respective daylight-saving transitions and the usual gap between them briefly shifts by an hour. If a meeting is being planned more than a few weeks out, setting the reference date to the actual meeting date (rather than leaving it on today) is what keeps the highlighted overlap column correct.
Yes — the timeline is calculated for the reference date you pick, using each city's real time zone rules for that specific date, including daylight saving adjustments where applicable.
It marks the hour(s) where every city you've added is simultaneously within its own working hours — the best time to schedule a meeting everyone can actually attend.
Yes — each city you add gets its own start and end time, so you can account for someone who works earlier or later than the standard 9-to-5.