CALENDAR TOOL · INTERVAL OVERLAP
Calendar tool: detect overlapping intervals
Check a proposed meeting against four existing events and see how time zones, endpoint rules, buffers and tentative events decide the answer.
Your experiment
Book 10:00-10:30 UTC. The design review E2 was created in India as 15:00-16:00 at +05:30, which is 09:30-10:30 UTC, but the tool compares stored wall-clock values and finds the slot free. Compare in UTC, then probe the endpoints at 10:30 and the tentative 1:1 at 11:00.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
One fictional day; times are minutes after 00:00 UTC, and E2 carries a fixed +05:30 offset (no daylight-saving rules). Real overlap is defined here as a half-open overlap of UTC instants with a confirmed event; tentative events and buffers are policy choices, reported separately. No calendar API is called, and recurring events, all-day events and multiple attendees are not modeled.
Overlap is a question about instants
Two meetings conflict when their time ranges intersect. Written as half-open intervals [start, end), a proposed meeting overlaps an event exactly when proposed start < event end and event start < proposed end, so back-to-back meetings that share an endpoint do not conflict. That test is only meaningful if both ranges are expressed in the same clock. The fixture calendar has four events on one day: Standup E1 09:00-09:30 UTC, Design review E2 created in India as 15:00-16:00 at +05:30 (09:30-10:30 UTC), a tentative 1:1 E3 11:00-11:30 UTC and Customer call E4 13:00-14:00 UTC.
The opening run: double-booked by a wall clock
The proposed meeting is 10:00-10:30 UTC and Compare times is set to stored wall-clock values. The tool reads E2 as 15:00-16:00 and finds no overlap with 10:00-10:30, so it answers free and books the slot. In real time E2 runs from 09:30 to 10:30 UTC and the two meetings overlap for thirty minutes. Switch Compare times to UTC instants and the same check reports E2 and refuses the slot. Converting every time to an instant first is the fix; the interval rule cannot repair a comparison between different clocks.
Failure boundary: endpoints and buffers
With UTC instants, move Proposed start to 630 (10:30). The meeting runs 10:30-11:00: it touches the end of E2 and the start of E3 but overlaps neither, and the half-open rule books it. Switch Interval rule to Closed [start, end] and both touching endpoints count, so the slot is refused without a real overlap. Return to half-open and set Buffer around the meeting to 5 minutes: the widened range 10:25-11:05 now intersects E2 and E3, and the refusal is a policy choice, reported as such. At 615 (10:15) the slot overlaps E2 and, with UTC instants, is correctly refused under either rule.
Tentative events and the other controls
With UTC instants and Proposed start 645 (10:45-11:15), the only overlap is the tentative E3. Treat tentative events as busy refuses the slot; turn it off and the meeting is booked, and the run reports it as correct because no confirmed event overlaps. Duration changes the proposed end: from the opening 10:00 start, 120 minutes reaches 12:00 and now also crosses E3 in the wall-clock reading. The wall-clock error also works the other way: start 900 (15:00 UTC) is free in real time, but the naive check refuses it because E2’s stored wall clock says 15:00-16:00.
Reading the run and its limits
Play replays the request, one comparison per existing event, the tool’s decision and the outcome over sixty inspection seconds; Next event, Restart, Speed and Inspection time control the replay, and an input change recomputes it. The table lists each event in UTC, the zone it was created in, its status, the tool verdict with its reason, and whether a real confirmed overlap exists. The day, events and +05:30 offset are fixed; there are no daylight-saving transitions, recurring series, all-day events, multiple attendees or free/busy API calls, which the linked articles discuss.