Merging a list of time-range tuples that have overlapping time-ranges
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Merging overlapping time ranges is a standard interval problem. It shows up in booking systems, uptime reports, employee schedules, and log analysis, where several small intervals need to be collapsed into the smallest set of continuous ranges.
Sort First, Then Scan Once
The clean solution is to sort intervals by start time and then walk through them once. Sorting matters because once the ranges are ordered, any overlap can only happen with the interval most recently added to the result.
Suppose the input is [(1, 3), (2, 5), (8, 10), (9, 12)]. After sorting, the first two intervals overlap and become (1, 5). The last two overlap and become (8, 12). The final result is [(1, 5), (8, 12)].
The key rule is simple: if the next interval starts before or at the end of the last merged interval, extend the last merged interval. Otherwise, start a new merged interval.
Python Implementation
Output:
The time complexity is dominated by sorting, so the full algorithm is O(n log n). The scan itself is linear.
Working With Real Timestamps
In real applications, you usually work with datetime values rather than integers. The algorithm stays the same because Python can compare datetime objects directly.
That produces two merged blocks: one morning block and one afternoon block.
Decide Whether Touching Ranges Should Merge
A practical detail is how to treat touching intervals. If one range ends at 10:00 and the next starts at 10:00, some systems consider them continuous and merge them. Others keep them separate.
The current implementation merges touching ranges because it uses start <= last_end. If you want strict overlap only, change the test to start < last_end.
That choice is business logic, not algorithm logic. Calendar applications often keep touching meetings separate, while billing windows or machine uptime windows often merge them.
Why This Approach Is Better Than Pairwise Comparison
A common first attempt compares every interval with every other interval and repeatedly merges matches. That works for small inputs, but it is slower and much harder to reason about. Repeated pairwise merging can also create subtle bugs when one merged range now overlaps a later interval that was already checked.
Sorting once avoids that mess. At any point, the only interval that matters is the last merged one. That makes the code easier to test and easier to explain.
Common Pitfalls
The most common bug is forgetting to sort before merging. Without sorting, you can merge some overlaps and still leave others fragmented because intervals arrive in an arbitrary order.
Another mistake is not validating that each tuple has start <= end. If bad input is possible, normalize or reject it before merging.
Developers also often hard-code the inclusive boundary rule without confirming requirements. Whether touching intervals merge should be explicit, because changing <= to < changes the result for edge cases.
Finally, watch time zones when using datetime. Mixing naive and timezone-aware timestamps can raise errors or create incorrect ordering.
Summary
- Sort intervals by start time before merging.
- Scan once and compare each range with the last merged range.
- The standard solution runs in
O(n log n)time. - '
<=merges touching ranges, while<keeps them separate.' - The same algorithm works for integers, floats, and
datetimevalues.

