News Search API Date Filters: Do not Lose the Last Day

An integration of a news search API can lose its last day when a date-only end bound between the interfaces is copied. The query still succeeds. The missing coverage gives the appearance of an empty news cycle as opposed to a request for the wrong interval.

Announcement of the standalone Web Search API, by AWS on November 10, 2026, gives a direct option in addition to the MCP connector.

The AgentCore developer guide defines a key distinction for news searches. An MCP “to” value with a date only represents the whole day, while a date-only SDK or CLI “publishedBefore” value represents midnight UTC at the start of that day. Both use inclusive time bounds. Copying the date does not reflect the search window.

Define the day before making the request

The choice is yours on whose calendar defines the day. “November 12” can be the day in the publisher’s time zone, the user’s time zone, or a day in UTC. These are all different intervals. The choice is stored in the request, not just a date.

A good internal practice is including the day’s start instant and not including the next day’s start. This half-open interval allows adjacent briefings to meet without touching the same point in time. This choice is up to the application, and the provider’s endpoint can use other rules.

To convert to UTC, find the local midnight in the named time zone, calculate both of them, and convert. Not every calendar day is exactly 24 hours long. Daylight saving time is one of the reasons to determine the next local midnight rather than adding a certain number of seconds.

One briefing, two boundary mistakes

In this constructed example, a research assistant is preparing a briefing covering November 12, 2026, in Asia/Jerusalem time. They need to find articles that were published that day, regardless of when the event documented occurred.

The first bound is November 12, 2026, at 00:00:00 in the named time zone (which is November 11, 2026, at 22:00:00 in UTC). The second, exclusive bound, is November 13, 2026 at 00:00:00 in the named time zone (which is November 12, 2026 at 22:00:00 in UTC). Publication timestamps at or after the first instant and strictly before the second instant should be accepted.

Let’s say article A was published at November 12, 2026 at 16:00:00 UTC. It should be included in the briefing. If a migration sends November 12, 2026 at 00:00:00 UTC as the end bound, that becomes the endpoint. Article A is published outside that bound, and therefore, not included in the briefing.

B was published at November 12, 2026 at 22:00:00 UTC. That is the next local day’s start, therefore it is out of scope of this briefing. If the adapter sends an instant that represents the upper bound of an end point that is inclusive, article B would pass the time filter of the endpoint.

Translate the Interval, then Check Membership

For an inclusive endpoint, one potential adapter strategy is to request through the next-day start and remove returned records at that instant before assembling the briefing. This avoids approximating a “last moment” smaller than the endpoint’s timestamp precision.

This strategy does have a limitation: Filtering after retrieval cannot recover an in-window article displaced by an out-of-window result in a capped ranking. Keep the result cap visible in evaluation. Where the endpoint supports a precise exclusive bound, use its documented behavior instead.

For the constructed briefing, the final membership check includes A and excludes B. Retain the actual provider request with the original day and its normalized time interval, including the named time zone. A reviewer should be able to tell the difference between a bad conversion and an irrelevant search result.

Test the adapter without relying on today’s headlines

Make fixture records just before the start, exactly at the start, just before the end, and exactly at the end. Fix the fixture’s timestamp precision. Expected membership is outside, inside, inside, outside.

Run those records through the code that serializes the request and the code that checks returned timestamps. Inspect the serialized values and the recorded timestamps. A correct display label can cover up an incorrectly encoded API request.

Repeat the test for each calling route. For an MCP-to-API migration, compare normalized time intervals instead of requiring identical result lists from a changing search index. Perform a separate live retrieval check to assess if the relevant coverage is available; a boundary fixture does not assess index coverage or rankings.

Maintain the publication time with the evidence.

Webz.io’s News Search API supports natural language queries, date filters, source filters, and language filters. Structured results consist of article details and passages. Use date filters and source filters to limit coverage and include the publication metadata with the passage given to the model.

The adapter should interpret the selected endpoint’s actual date contract. A shared field name does not prove that different services accept the same syntax or end-bound rules.

Publication time denotes the timeline of the source; the discovery and delivery stages of a pipeline represent later steps. If a result does not have a usable publication time, route it to an explicit unknown time path and do not set the time to November 12.

Prior to releasing the migration, have another developer reconstruct the briefing interval from the saved request. They should get the same local time, the same UTC time, and the same A/B membership. If they cannot, then the date filter is not a reliable boundary for the answer.