Meeting Time Overlap Finder
How it works
Each participant's local start and end hour is converted to UTC by subtracting their offset — on purpose without wrapping the result into 0-24. That keeps every window on one continuous timeline anchored to a single day, which is what lets working hours that cross midnight in UTC (a very negative or very early offset, or hours late enough in the local day) compare correctly against everyone else's. The overlap is then just the latest of all the start times to the earliest of all the end times. If that latest start is at or after that earliest end, there is no shared working window.
Frequently asked questions
Why can the UTC hours shown for one participant go negative or past 24?
That is the correct way to represent a working window that falls on the UTC calendar day before or after the day everyone else is being compared against — not an error. A value of -2, for instance, means 22:00 the previous UTC day; a value of 26 means 02:00 the next UTC day. The overlap itself is still worked out with plain arithmetic on this continuous scale, which is what makes it correct across a date-line-crossing set of offsets.
What if there is no overlap at all?
The result area says so plainly rather than showing a meaningless range. Some combinations of working hours and offsets genuinely never overlap on the same UTC day — the fix is to widen someone's working hours, not a bug in the math.
Does this account for daylight saving time?
No — enter each participant's current UTC offset (for example -4 for US Eastern in summer, -5 in winter) rather than a timezone name, and it stays correct for that moment. A page with no bundled timezone database cannot know which DST rule applies to a given city on a given date, so asking for the offset directly is the only way to stay accurate rather than silently guessing wrong half the year.