authorizedTimeWindows, preferredTimeWindows and resourceTags. Each section states one rule, with a link to the API reference where the exact behavior is written. The last section shows how to check a solution against its windows.
A workingTimeWindow is the window of a resource, not of a stop. A stop can only be served while one of the resources works.
What a window limits
A window limits the start of service, not the arrival. The start of service is thebeginTime of the stop in the solution. A resource that arrives before begin waits until begin, and the stop is still planned.
The wait is not a delay. For one stop, the wait is beginTime minus arrivalTime. The waitingDuration of a tour is the total of these waits over the whole tour.
For example, a clinic accepts deliveries from 10:00. A van reaches the clinic at 08:13, starts service at 10:00, and leaves at 10:10. The wait is about 1 hour 47 minutes, and the delay is zero.
See authorizedTimeWindows for the rule.
Hard or preferred window
UseauthorizedTimeWindows for a hard window. Outside all of them, the stop can’t be planned at all, and it appears in unaffectedStopIds. Use preferredTimeWindows for a preferred window. A late start is allowed, and it costs the minimizeDelay objective.
To choose, ask the business one question: what should happen if the fleet can’t reach the window? If a late visit is acceptable, use a preferred window. If a visit outside the window is useless, for example because the site is closed, use a hard window. A contractual window is not automatically a hard one. Hard vs soft constraints explains why.
A preferred window is soft at its end only. The delay of a stop is the start of service minus the end of the window. A stop that starts before end has no delay.
A preferred window is hard at its start. The engine never starts service before begin, and a resource that arrives early waits. A preferred window can therefore drop a stop. For example, the window opens at 21:00 and every resource stops working at 20:00. The stop stays in unaffectedStopIds. If the business says deliver at 21:00 if possible, and otherwise earlier, don’t use a preferred window.
When the preferred window closes before the authorized window opens, the engine serves the stop inside the authorized window. For example, the authorized window is 10:00 to 12:00 and the preferred window is 06:00 to 06:30. The engine serves the stop at 10:00, inside the authorized window. The delay is 3 hours 30 minutes, the time between 06:30 and 10:00. When the preferred window opens after the authorized window closes, the engine doesn’t plan the stop. When the preferred window sits inside a wider authorized window, the van waits for the preferred window to open.
See preferredTimeWindows for the rule.
Several windows on one stop
Each of the two fields takes an array. A stop with several windows can be served in any one of them. For example, a shop that opens in the morning and again in the evening has two authorized windows, and the engine picks the one that fits the tour.Windows reserved for some resources
A window can carryresourceTags. Only the resources that carry a matching tag can use this window. The tags of a resource are in its tags field.
- A resource that carries any one of the tags of a window can use it. A resource doesn’t need all the tags.
- A resource without a matching tag doesn’t see this window. It can still use the windows without
resourceTags, and any other window that shares one of its tags. - A stop whose only windows are tagged can’t be served by a resource without the tag. The stop appears in
unaffectedStopIds. - The same rules apply to
preferredTimeWindows. If a stop has only tagged preferred windows and no authorized window, a resource without the tag can’t serve the stop. If the stop also has an authorized window with no tag, that resource serves the stop there, with no delay.
certified, and an open window from 10:00 to 12:00. A van with the tag certified can use the first window. A van without the tag waits until 10:00.
See TaggedTimeWindow for the rule.
Finishing before a deadline
A window bounds the start of service, so a stop can end afterend. The stop ends at the start of service plus its operationDuration.
If the business says the stop must be done by 15:00, subtract operationDuration from end yourself. For a 15-minute operation, set end to 14:45.
tz value. See Dates and time zones.
Checking the solution
TheisValid and violations fields of a tour only report broken hard constraints. A stop that the engine dropped, or a late start against a preferred window, doesn’t appear there. Read these fields of the solution as well:
unaffectedStopIdslists the stops that no window, or no other constraint, allowed.beginTimeof each stop is the start of service. Compare it with the authorized windows that apply to the resource of the tour. Ignore the windows whoseresourceTagsthe resource doesn’t carry.delayof each stop is the delay against its preferred windows, as an ISO 8601 duration.waitingDurationof each tour is its total waiting time.
tz, for example 2026-10-29T10:00:00+01:00. The plan can hold local times, for example 2026-10-29 10:00. Don’t compare the two as strings. Convert both to instants with the tz of the plan, then compare the instants.
Example plan
This plan has one van with no tags and two stops. The clinic has two authorized windows, and the first one is reserved for the tagcertified. The shop has a preferred window that closes at 06:30, before the van starts working at 08:00.
What the solution shows
The sandbox returns these waypoints for the plan, with the offset ofEurope/Paris and with seconds. The other fields are left out.
- The shop is served at 08:01:06. Its preferred window closed at 06:30, so the delay is 1 hour 31 minutes 6 seconds. The stop is served late, not dropped.
- The clinic is reached at 08:13:18, but the van has no tag
certified. It can’t use the window from 08:00 to 09:00, so it waits until 10:00. The wait is 1 hour 46 minutes 42 seconds, thewaitingDurationof the tour. The delay is zero. unaffectedStopIdsis empty, because both stops were planned.
A check in code
These snippets read the solution you got for the example plan. They list the unplanned stops, then print for each stop if its start of service falls inside an authorized window that applies to the resource, and its delay. They convert every time to an instant with thetz of the plan.
PT1H31M6S is the value you would act on: it tells you the shop is served late.
The TypeScript helper reads a local time by looking at how the plan’s tz shows it. It can be wrong by an hour close to a clock change. For those times, send an explicit offset. See Dates and time zones.
