A time window is the period between a start and end time in which a network location, such as a stop in a route analysis, will be visited by a route. Time windows are frequently used to model appointment or delivery times.
Note:
A time window describes when a vehicle can arrive at a location; it doesn't describe the time period during which all business at the location must be completed.Route, vehicle routing problem, and last mile delivery are the three network analysis types that incorporate time windows. For both route and vehicle routing problem, the time windows can be configured for a specific date, a generic weekday, or the current date. However, for last mile delivery, the time windows can only be configured for a specific date.
Learn more about dates and times in a network analysis
Time windows in a route analysis
The route solver attempts to find the least-cost route through a series of stops while respecting chosen restrictions on the network and honoring all time windows. If time window violations are inevitable, the solver attempts to minimize the total violation time.
Time windows in a route analysis are defined using fields in the Stops input class:
| Network analysis class | Time window field |
|---|---|
Stops |
TimeWindowStart—The beginning of the time window when the stop can be visited. |
|
TimeWindowEnd—The end of the time window when the stop can be visited. |
Time windows are automatically used in the analysis when any of the time window fields are populated.
The time specified for each time window can be interpreted using the local time zone of each input location or in Coordinated Universal Time (UTC). When using a Route analysis layer, the time zone for time window fields can be specified using the Time Zone for Time Fields parameter on the Make Route Analysis Layer geoprocessing tool dialog box or the Reference Time Zone drop-down list on the Route Layer ribbon. When using a Route solver object in the arcpy.nax Python module, use the timeZoneForTimeWindows property.
When time windows are in use, it is not necessary to specify an analysis time of day, as the time window of the first stop will be used to determine when the route begins. However, if you specify an analysis time of day that represents, for example, the start of a driver's shift, this will be factored into the arrival and departure times at all stops. If the route begins before the first stop's time window, a wait time will be added at the first stop. If the route begins after a stop's time window has passed, a violation time penalty will be incurred. The time window date should match the date specified for the time of day for the route analysis.
Any wait time or violation time incurred by the route is included in the output. The total wait time and violation time for each route can be found in the Routes output class in fields prefixed with TotalWait_ and TotalViolation_, respectively. The wait time and violation time incurred at each stop along a route can be found in the Stops output class in fields prefixed with Wait_ and Violation_, respectively. The fields in the output Stops class prefixed with CumulWait_ and CumulViolation_ represent the cumulative wait time and violation time up to that point along the route.
Time windows in a vehicle routing problem analysis
The vehicle routing problem solver attempts to find the least-cost route to service orders, making necessary depot visits, and taking necessary breaks while respecting chosen restrictions on the network and honoring all time windows. If time window violations are allowed and inevitable, the solver attempts to minimize the total violation time.
Time windows in a vehicle routing problem analysis can be defined for Orders, Depots, and Breaks classes using the following fields:
| Network analysis class | Time window field |
|---|---|
Orders |
TimeWindowStart—The beginning of the first time window when the order can be visited |
TimeWindowEnd—The end of the first time window when the order can be visited | |
TimeWindowStart2—The beginning of the second time window when the order can be visited | |
TimeWindowEnd2—The end of the second time window when the order can be visited | |
Depots | TimeWindowStart—The beginning of the first time window when the depot can be visited |
TimeWindowEnd—The end of the time first window when the depot can be visited | |
TimeWindowStart2—The beginning of the second time window when the depot can be visited | |
TimeWindowEnd2—The end of the second time window when the depot can be visited | |
Breaks | TimeWindowStart—The beginning of the time window when the break can occur |
TimeWindowEnd—The end of the time window when the break can occur |
Legacy:
When using a VehicleRoutingProblem solver object with schema version One in the arcpy.nax Python module, the first time window in the Orders and Depots classes is defined using fields called TimeWindowStart1 and TimeWindowEnd1 instead of TimeWindowStart and TimeWindowEnd.
The input Routes class also has time window fields that are used to specify the period in which a route can begin its journey:
| Network analysis class | Time window field |
|---|---|
Routes |
EarliestStartTime—The beginning of the time window in which the route can begin its journey |
LatestStartTime—The end of the time window in which the route can begin its journey |
Time windows are automatically used in the analysis when the time window fields are populated. The time window date must match the default date configured for the analysis.
The time specified for each time window can be interpreted using the local time zone of each input location or in Coordinated Universal Time (UTC). When using a Vehicle Routing Problem analysis layer, the time zone for time window fields can be specified using the Time Zone for Time Fields parameter on the Make Vehicle Routing Problem Analysis Layer geoprocessing tool dialog box or the Reference Time Zone drop-down list on the VRP Layer ribbon. When using a VehicleRoutingProblem solver object in the arcpy.nax Python module, use the timeZoneForTimeWindows property.
Any wait time or violation time incurred by the route is included in the output. The total wait time and violation time for each route can be found in the Routes output class in the TotalWaitTime and TotalViolationTime fields, respectively. The wait time and violation time incurred at each order, break, or depot along a route can be found in the WaitTime and ViolationTime fields, respectively. The CumulWaitTime and CumulViolationTime fields for an order, depot, or break represent the cumulative wait time and violation time, respectively, up to that point along the route.
You can set the MaxViolationTime and MaxViolationTime2 fields in the input orders and the MaxViolationTime field in the input breaks to control how much time window violation is acceptable for your analysis. To model time windows as a hard constraint, in which time window violations are not permitted, set the corresponding MaxViolationTime and MaxViolationTime2 fields to zero.
Legacy:
When using a VehicleRoutingProblem solver object with schema version One in the arcpy.nax Python module, the MaxViolationTime field in the Orders class is called MaxViolationTime1.
Time windows in a last mile delivery analysis
The last mile delivery solver attempts to find a well-clustered and low-cost set of routes to service orders while respecting chosen restrictions on the network and constraints on the problem such as time windows. If time window violations are allowed and inevitable, the solver attempts to minimize the total violation time.
Time windows in the last mile delivery analysis are defined on the Orders class using the following fields:
| Network analysis class | Time window field |
|---|---|
Orders |
TimeWindowStart—The beginning of the time window when the order can be visited |
TimeWindowEnd—The end of the time window when the order can be visited |
The input Routes class also has time window fields that are used to specify the period in which a route can begin its journey:
| Network analysis class | Time window field |
|---|---|
Routes |
EarliestStartDate—This works in conjunction with the EarliestStartTime to define the beginning of the time window in which the route can begin its journey, specifying the date portion of it. |
EarliestStartTime—This works in conjunction with the EarliestStartDate to define the beginning of the time window in which the roue can begin its journey, specifying the time portion of it. | |
StartFlexibility—Indicates how long after the earliest allowed route start time the route can start. Uses the units designated by the TimeFieldUnits parameter. |
Both the EarliestStartDate and the EarliestStartTime can be designated for each feature in the Routes class or for all features using the EarliestRouteStartDate and EarliestRouteStartTime parameters.
Time windows are automatically used in the analysis when the time window fields are populated. The time window dates for both the Orders and Routes classes must all be specific dates and within a year of each other.
The time specified for each time window can be interpreted using the local time zone of each input location or in coordinated universal time (UTC). When using a Last Mile Delivery analysis layer, the time zone for time window fields can be specified using the Time Zone for Time Fields parameter on the Make Last Mile Delivery Analysis Layer geoprocessing tool dialog box or the Reference TimeZone drop-down list on the Last Mile Delivery Layer ribbon. When using a LastMileDelivery solver object in the arcpy.nax Python module, use the timeZoneForTimeFields property.
Any wait time or violation time incurred by the route is included in the output. The total wait time and violation time for each route can be found in the Routes output class in the TotalWaitTime and TotalViolationTime fields, respectively. The wait time and violation time incurred at each order along a route can be found in the WaitTime and ViolationTime fields, respectively.
You can set the MaxViolationTime field in the input orders to control how much time window violation is acceptable for your analysis. To model time windows as a hard constraint, in which time window violations are not permitted, set the MaxViolationTime to zero.
Time window example
The following example illustrates time windows used with a route analysis used to find the optimal route to visit three stops—a, b, and c. The time window for each stop is given by its TimeWindowStart and TimeWindowEnd fields.
The route can begin from point a at any time between 8:00 and 9:00 a.m. However, it should not reach point b before 9:15 a.m. As shown below, the route reaches b at 9:08:24 a.m.
Since b should be visited only between 9:15 and 9:30 a.m., the route waits at b for 6 minutes and 36 seconds and departs at 9:15 a.m. This wait time is stored in the Wait_TravelTime field of stop b as 6.6 minutes and is added to the total time taken for the route. The Cumul_TravelTime field for a stop stores the total time taken to reach it. The cumulative travel time of b is 15 minutes (8 minutes and 24 seconds of travel and 6 minutes and 36 seconds of waiting to honor the time window of stop b).
The route departs from stop b at 9:15 a.m. and reaches stop c at 9:35:34 a.m. However, stop c has a time window of 9:15 to 9:30 a.m. Because the route is unable to honor the time window of stop c, a violation time of 5 minutes and 34 seconds is incurred and is stored in the Violation_TravelTime field as 5.58 minutes.
