Home / Recipes / Query an exact window, down to the minute
Worked queryQuery an exact window, down to the minute
/search in keyword mode. The parameters matter less
than the reasoning behind them, so that is most of what is below.
The request
GET /search
?q=<subject>
&from=20260729T140000
&to=20260729T160000Why these parameters
Both bounds accept a full timestamp, not just a date. For event studies — what was published in the two hours around an announcement — that precision is the whole exercise, and a whole-day window buries the signal in everything else that happened.
The obvious approach, and why it loses
The obvious approach is a whole-day window, because that is what date filters usually accept elsewhere, and it dissolves the effect you are trying to measure. If an announcement lands at two in the afternoon, the day around it contains every unrelated thing published in the same twenty-four hours, and the two-hour response is a small fraction of that. The other shortcut, filtering client-side after retrieving the day, works but wastes most of the result budget on rows you discard, and it silently caps what you can see once the day's volume exceeds your page limit. Bounding both ends with timestamps puts the constraint where the index can act on it.
When it returns too much, or too little
Too little is the common failure and it is usually real: a tight window around an announcement genuinely contains few articles, and the temptation to widen until the count looks respectable destroys the measurement. Widen symmetrically or not at all, and report the window you used. Too much means the window has caught an unrelated event — check what else was happening before assuming your subject produced the volume. If you are comparing several windows, hold their lengths identical even when that means a window with almost nothing in it, because unequal windows are the single most common way these comparisons go wrong.
How you would know it is working
Validate the clock before trusting the counts. Take one article you can verify independently, compare its indexed publication time against the time on the publisher's own page, and do that for a handful of outlets in your set. What you are looking for is systematic offset and whether a publisher stamps first publication or last update; both are common and neither is announced. Once you know the spread for your outlets, you know the smallest window the method can support. Below that, the recipe is measuring timestamp convention rather than publication behaviour, and no amount of care in the analysis recovers it.
When this is the wrong tool
Publication timestamps are not observation timestamps. They record when a publisher released a piece, which can differ from when the event occurred by minutes or by days, and outlets vary in whether they stamp first publication or last update. For an event study that turns on ordering within a narrow window, that variance is the same size as the effect being measured. This recipe is sound for comparing coverage volume across precisely bounded windows and unreliable for establishing sequence between two articles published minutes apart. If ordering is the question, see the first-mover recipe, and treat its answer as indicative rather than forensic.
Running it for real
Response fields, failure modes, adaptations and scheduling cost: Query an exact window, down to the minute, in the docs.