Half-Open Time Window
A half-open time window is a time interval that includes its start timestamp and excludes its end timestamp, commonly written as [start, end), to avoid overlap between adjacent periods.
A half-open time window is a standard way to represent a time range where events at the start timestamp are included, while events at the exact end timestamp are excluded. For example, a one-minute window from 10:00:00 to 10:01:00 includes trades with timestamps greater than or equal to 10:00:00 and strictly less than 10:01:00.
This convention is widely used for OHLCV candles, historical market data queries, and time-series aggregation because it prevents the same event from being counted in two adjacent periods. The next interval begins exactly where the previous one ends, so [10:00:00, 10:01:00) is followed by [10:01:00, 10:02:00).
Without half-open boundaries, systems may disagree about whether data at the boundary belongs to the earlier candle or the later candle. That can create duplicate volume, missing trades, inconsistent candle values, or off-by-one timestamp errors.
Why Half-Open Time Windows Matter
Half-open time windows matter because market data is often aggregated into precise periods such as one second, one minute, one hour, or one day. A clear inclusion rule is needed so every trade, quote, or update belongs to exactly one period.
For developers, this convention helps ensure that paginated historical requests, OHLCV calculations, and backfills are deterministic. It also makes reconciliation easier because two systems can compare data using the same interval semantics.
In financial and crypto market data, even a single boundary event can affect open, high, low, close, or volume values. Using half-open windows helps avoid ambiguity at period boundaries.
How does a half-open time window work?
A half-open time window includes records where the event timestamp is greater than or equal to the start time and less than the end time.
For a window [2024-01-01T00:00:00Z, 2024-01-01T00:01:00Z), an event at 2024-01-01T00:00:00Z is included. An event at 2024-01-01T00:00:59.999Z is included. An event at exactly 2024-01-01T00:01:00Z is excluded and belongs to the next window.
This approach makes consecutive periods continuous without overlapping.
Why are half-open intervals used for OHLCV candles?
Half-open intervals are used for OHLCV candles because they define exactly which trades belong in each candle. The open price comes from the first trade in the interval, the close price comes from the last trade before the end boundary, and volume is calculated only from trades inside the interval.
If both the previous and next candles included the same end timestamp, a boundary trade could be double counted. If neither included it, the trade could be missed. Half-open windows avoid both problems.
What problems do half-open time windows prevent?
Half-open time windows prevent duplicate counting, missing boundary events, and inconsistent period assignment. They are especially useful when historical data is fetched in batches, when candles are recalculated during backfill, or when datasets are compared across systems.
They also reduce confusion when APIs accept time_start and time_end parameters, because clients can safely chain requests by using the previous response end time as the next request start time.
Real-World Example
A developer requests one-minute OHLCV candles for BTC/USD from 12:00:00 to 12:03:00. With half-open windows, the API can build three non-overlapping intervals:
[12:00:00, 12:01:00)[12:01:00, 12:02:00)[12:02:00, 12:03:00)
A trade at exactly 12:01:00 belongs to the second candle, not the first. This prevents the trade from being counted twice and ensures that each candle has a deterministic set of source trades.
Half-Open Time Window and Market Data API
In CoinAPI Market Data API workflows, half-open time windows are important for OHLCV retrieval, historical data pagination, period boundary handling, and backfill logic.
When applications request historical candles or aggregate trades into time buckets, using [start, end) semantics helps align results across adjacent periods. It also helps developers avoid gaps or overlaps when splitting long time ranges into multiple API requests.
Clear time-window semantics are especially important for systems that compare live, provisional, and finalized market data.