Learning Objectives
By the end of this lesson you will be able to:
- Distinguish between half-open [start, end) and closed [start, end] intervals
- Explain the inclusive/exclusive semantics used in booking systems
- Design test cases that verify interval boundary behavior
- Describe the SQL WHERE clause implications of each interval type
- Recognize common interval bugs caused by semantic mismatch
Two Ways to Define an Interval
A date range has two endpoints: a start and an end. The question is: are those endpoints themselves included in the range?
Closed interval [start, end]: both endpoints are included. A booking from June 1 to June 5 covers June 1, 2, 3, 4, and 5.
Half-open interval [start, end): the start is included but the end is excluded. A booking from June 1 to June 5 covers June 1, 2, 3, and 4 only. June 5 is not part of this booking.
Neither convention is universally correct. What matters is that the system is consistent and that testers know which convention a particular system uses.
Why Half-Open Intervals Are Common
Half-open intervals dominate in software for one important reason: they make contiguous ranges non-overlapping by definition. If booking A ends on June 5 (exclusive) and booking B starts on June 5, they are back-to-back with no gap and no overlap. With closed intervals, the same pair would overlap on June 5.
This matters for room booking, appointment scheduling, shift management, and any domain where consecutive slots must be adjacent but not overlapping. The half-open convention eliminates the need for special-case logic at boundaries.
Inclusive/Exclusive Semantics in Practice
The challenge in QA is that the system's documentation, the UI, and the backend may use different conventions without being explicit about it. A booking form might display "Check-out: June 5" but internally store and process June 5 as exclusive — meaning the guest's last night is June 4.
This semantic mismatch is a common source of bugs:
- Users see "June 1–June 5" and expect 5 nights
- System interprets it as [June 1, June 5) and bills for 4 nights
- Or the reverse: system uses [June 1, June 5] and the room is unavailable on June 5 when the next guest expects to check in
SQL WHERE Clause Implications
In SQL, the convention must be explicit in the query.
Half-open (recommended for daily bookings):
WHERE check_in >= '2025-06-01' AND check_out < '2025-06-05'
Closed (appropriate for timestamp-level precision):
WHERE check_in >= '2025-06-01' AND check_out <= '2025-06-05 23:59:59'
A developer who uses <= when the system convention is < will produce off-by-one availability bugs that are very hard to reproduce — they only appear when a booking ends on exactly the same day another begins.
Test Cases for Interval Boundaries
To distinguish half-open from closed behavior, design a test that checks the exact boundary point:
| Scenario | Half-open [start, end) result | Closed [start, end] result |
|---|---|---|
| New booking starts on end date of existing booking | Allowed | Rejected (overlap) |
| New booking ends on start date of existing booking | Rejected (overlap) | Rejected (overlap) |
| New booking equals existing booking exactly | Rejected (duplicate) | Rejected (duplicate) |
The most diagnostic test: submit a booking from June 5 to June 10, then submit a second booking from June 10 to June 15. If the system uses half-open intervals, both should be accepted. If it uses closed intervals, the second booking should be rejected because June 10 is already occupied.
Empty and Degenerate Intervals
An interval where start equals end has different meanings depending on convention:
- In a half-open interval, [June 5, June 5) is empty — it contains no dates
- In a closed interval, [June 5, June 5] contains exactly one date — June 5
Systems that accept start == end for half-open intervals effectively accept zero-duration bookings, which may or may not be a bug depending on the domain.
Summary
Interval semantics (open vs closed endpoints) determine whether the boundaries of a date range are included or excluded. Half-open intervals prevent boundary overlaps by design, making them the preferred choice for consecutive-slot systems. QA must determine which convention a system uses and then specifically test the boundary point — the test case where a new booking starts exactly when an existing one ends is the most reliable way to reveal interval convention bugs.