Time of day can be critical in certain types of network analysis. It takes much longer to drive across the city during rush hour than it does during the middle of the night because of increased traffic. Public transit service runs on a schedule and may be unavailable during some times of day and days of the week, making some journeys difficult or impossible.
Dates and times in network analysis
Two things are required to use a date and time in your network analysis:
- The network analysis must be configured to use a travel mode that uses traffic or public transit.
- The network analysis must be configured to use the desired date and time.
Not every network dataset or travel mode is configured to be time aware. The results of a network analysis will vary by time of day only if the analysis is configured to use traffic or public transit data. Specifically, the analysis travel mode's impedance attribute must use the Traffic or Public Transit evaluator.
Learn more about how historical and live traffic data are used and configured
Even if the analysis's travel mode uses traffic or public transit, the analysis will be solved in a time neutral way if the analysis is not explicitly configured to use a date and time. Impedance attributes that use the Traffic evaluator are configured fall back to the value returned by a different impedance attribute in the time neutral case. If the travel mode's impedance attribute uses the Public Transit evaluator, transit lines are considered restricted, and the result represents travel without using public transit.
Arrival and departure times
In a closest facility analysis, you can choose whether the time of day will be interpreted as a departure time or an arrival time.
In a service area analysis, if the direction of travel is away from the facilities, the time of day is interpreted as a departure time, but if the direction of travel is toward the facilities, the time of day is interpreted as an arrival time.
The other network analysis solver types do not offer an arrival time option. All times of day are interpreted as departure times.
Generic weekdays and specific dates
When choosing a date for any analysis except for last mile delivery, you can use either a specific date, such as June 20, 2022, or you can use a weekday, such as Monday. You can also configure the analysis to always use the current date. The last mile delivery analysis requires that specific dates be used for all time fields.
For an analysis using traffic, a weekday is interpreted as the next instance of that day of the week. If you configure the analysis to solve for a Tuesday, and today is Monday, June 20, the analysis will solve for Tuesday, June 21. If you solve the analysis again later in the week, the analysis will solve for the next instance of a Tuesday, which is June 28.
For an analysis using public transit, a weekday is interpreted as truly generic. Only regular service defined in the Calendars table of the public transit data model is considered, and any exceptions to the regular service defined in the CalendarExceptions file are ignored.
Configure your analysis to use one of the following special dates to model a day of the week or the current date instead of a specific, static date:
- Today—12/30/1899
- Sunday—12/31/1899
- Monday—1/1/1900
- Tuesday—1/2/1900
- Wednesday—1/3/1900
- Thursday—1/4/1900
- Friday—1/5/1900
- Saturday—1/6/1900
Time zones
If your analysis is contained within a small geographic area, you may not need to consider time zones. However, if your input data covers a large geographic area that spans time zones, consider how times of day will be interpreted. You can choose whether the date and time specified for your analysis will be interpreted using the local time zone of each input location or in Coordinated Universal Time (UTC).
Consider as an example a Service Area analysis with facilities located in several major cities across the United States. Configure the analysis to interpret the time of day using the local time at each location if you want all the services areas to be generated at the same time of day in their local time zone. With this option, if the time of day is set to 8:00 a.m., facilities in eastern time will have a start time of 8:00 a.m. eastern time, facilities in central time will have a start time of 8:00 a.m. central time, and so on. The service area always models travel starting at 8:00 in local time but is staggered in real time.
On the other hand, configure the analysis to interpret the time of day using UTC if you want all the service areas to be generated starting simultaneously in real time. Setting time of day to 2:00 p.m. causes service areas to be generated for 9:00 a.m. eastern standard time for any facilities in the eastern time zone, 8:00 a.m. central standard time for facilities in the central time zone, 7:00 a.m. mountain standard time for facilities in the mountain time zone, and so on.
Note:
Last mile delivery analysis requires that the network dataset have a time zone attribute but still allows the choice between specifying input times in the local time zone of each input location or in coordinated universal time (UTC).
Learn more about how time zones are configured in network datasets
Time windows
For route, vehicle routing problem, and last mile delivery analyses, you can specify a time window, which defines 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.
Learn more about time windows in route, vehicle routing problem, and last mile delivery analysis