The Availability Algorithm: How Interval Merging Works

The question sounds simple. The answer is elegant.

"When are you free?" It is the most common scheduling question in professional life, and for someone managing multiple calendars across multiple organizations, it is surprisingly difficult to answer accurately.

manyCalendars answers it using a technique called interval merging. It is a well-known algorithm in computer science, and it is perfectly suited for calendar availability computation. Here is how it works, step by step.

Step 1: Collect all busy intervals

Every event on every connected calendar is a busy interval. It has a start time and an end time. A standup from 9:00 to 9:15 is the interval [9:00, 9:15]. A client call from 10:00 to 11:00 is [10:00, 11:00]. manyCalendars collects every event from every calendar source into a single flat list of intervals.

At this stage, the list might look chaotic. Events from different calendars overlap. Some are back-to-back. Some are nested inside others (a 30-minute focus block inside a 2-hour calendar hold). The list is not sorted. It is just a raw dump of every commitment from every source.

Step 2: Sort by start time

The algorithm sorts all intervals by their start time. This is the key step that makes everything else work. Once the intervals are sorted, you can process them left to right, and any overlapping intervals will be adjacent in the list.

After sorting, a day might look like this: [8:30, 9:00], [9:00, 9:15], [9:00, 10:00], [10:00, 11:00], [10:30, 11:30], [13:00, 14:00], [15:00, 16:00]. Notice how some intervals overlap and some are entirely contained within others. That is normal when multiple calendars contribute events to the same time range.

Step 3: Merge overlapping intervals

Now walk through the sorted list. Start with the first interval as your "current" merged interval. For each subsequent interval, check: does its start time fall before or at the current interval's end time? If yes, the two intervals overlap (or are adjacent), so extend the current interval's end time to whichever end time is later. If no, the current interval is complete, and you start a new merged interval.

Using the example above: [8:30, 9:00] and [9:00, 9:15] are adjacent, so they merge into [8:30, 9:15]. The next interval [9:00, 10:00] overlaps with [8:30, 9:15], extending it to [8:30, 10:00]. Then [10:00, 11:00] is adjacent, extending to [8:30, 11:00]. Then [10:30, 11:30] overlaps, extending to [8:30, 11:30]. Now there is a gap before [13:00, 14:00], so [8:30, 11:30] is finalized as one merged block. Then [13:00, 14:00] stands alone. Then [15:00, 16:00] stands alone.

The result: three merged busy blocks. [8:30, 11:30], [13:00, 14:00], [15:00, 16:00]. Seven original events collapsed into three contiguous blocks. That is the power of interval merging.

Step 4: Compute the complement

Your free time is the complement of your busy time within your working hours. If your work day runs from 8:00 to 18:00 and your merged busy blocks are [8:30, 11:30], [13:00, 14:00], and [15:00, 16:00], your free slots are: [8:00, 8:30], [11:30, 13:00], [14:00, 15:00], [16:00, 18:00].

Computing the complement is straightforward once you have the merged busy intervals. Walk through them in order. The gap between each pair of adjacent busy blocks is a free slot. The gap between the start of your work day and the first busy block is a free slot. The gap between the last busy block and the end of your work day is a free slot.

Step 5: Filter short slots

Not every free slot is actually usable. A 10-minute gap between back-to-back meetings is technically free time, but you cannot schedule a meaningful meeting in it. manyCalendars filters out slots shorter than 15 minutes by default. This keeps the availability output practical rather than technically correct but useless.

The threshold is configurable. If your meetings tend to be 25 minutes, a 15-minute minimum makes sense. If you regularly schedule 10-minute check-ins, you might lower the threshold. The point is that raw mathematical availability and practical availability are different things, and the filter bridges that gap.

Why this approach works so well

Interval merging is elegant because it scales linearly. Sorting the intervals takes O(n log n) time. The merge pass takes O(n). The complement computation takes O(n). Whether you have 5 events or 50, the algorithm runs in milliseconds. It does not matter how many calendars contribute events or how chaotically they overlap. The sorted merge reduces any input to a clean set of non-overlapping busy blocks.

It is also robust. It handles edge cases naturally: back-to-back events merge correctly, nested events (a meeting inside a calendar hold) resolve to the outer boundary, and events that span lunch or cross time zones are just intervals with different numbers. The algorithm does not care about context. It cares about start times and end times, and that is all it needs.

The next time someone asks "When are you free?" and you paste a clean list of available slots from manyCalendars, know that a quietly elegant algorithm produced that answer in the time it took you to click the button. Install manyCalendars and let the interval merge do the thinking for you.