The time of day (and possibly the date) changes for a vehicle when it crosses a time zone. If time zones are not configured on a network dataset that spans multiple time zones, time-of-day values in an analysis can be a source of confusion. Moreover, traffic-enabled network datasets can return incorrect travel times, and live-traffic network datasets can render traffic conditions for the wrong time if time zones are ignored. To avoid these problems, you can add an attribute to your network dataset to manage time zones.
This topic explains why configuring time zones on your network dataset may be necessary, and describes how to configure a time zone attribute.
Configuring a time zone attribute on a live-traffic enabled network dataset is always required; however, it isn't always necessary to configure a time zone attribute on network datasets that don't support live traffic. For example, if a network dataset that doesn't support live traffic falls entirely within a single time zone, you don't need to configure time zones. Also, configuring time zones is not necessary if you never perform network analyses using a time-based impedance with a start time.
Time zones and network analysis
To better understand why it is critical to set up a time zone attribute on a traffic-enabled network dataset that spans multiple time zones, assume that at 8:38 a.m. a route analysis traverses two adjacent edges, starting from one edge in the mountain time zone and continuing along another in the Pacific time zone. If a time zone attribute is not configured, the network dataset will ignore the time differential and retrieve the edges' travel times based on only one time zone. This means that instead of retrieving the travel time for the edge in the Pacific time zone for 7:38 a.m., it could retrieve the travel time for 8:38 a.m. or possibly some other time of the day, depending on the default time zone.
If time zones are configured properly, however, the cost of the edge in the mountain time zone is evaluated for 8:38 a.m. local time and the edge in the Pacific time zone is correctly evaluated for 7:38 a.m. local time. The accuracy of travel times in a traffic-enabled network dataset is thus maintained. Also, directions show time zone changes.
Regardless of whether a network dataset that spans multiple time zones is traffic enabled, configuring a time zone attribute makes it easier to enter and interpret time-of-day properties—such as time windows and arrival or departure times—because their time values always refer to local time. For example, assume you add two stops—one in the eastern time zone and another in the central time zone—and want to set both their time windows to 8:00 a.m. to 9:00 a.m. local time. If time zones aren't configured, you would have to manually convert one or both of the time window values to the default time zone. Alternatively, when time zones are configured on the network dataset, the times you enter are automatically set to the local time of the underlying edge, and Network Analyst manages the time conversions internally.
How network datasets handle time zones
Time zones have a temporal offset with respect to Coordinated Universal Time (UTC). Local rules specify what the UTC offset should be, whether daylight saving time is observed, and, if it is, the offset and date ranges for daylight saving. These rules can change frequently; keeping track of all current and past rules is a difficult task. Fortunately, later versions of Windows operating systems manage this by delivering any time zone changes in the world to your computer through Windows updates. The time zones and their rules are stored in the Windows registry.
The ArcGIS Network Analyst extension retrieves the UTC offsets and daylight saving time rules for time zones from the Windows registry. The conceptual diagram below shows a general overview of how this works.
A TimeZoneID field on the edge source features indicates the time zone the features are in. The TimeZoneID value is a foreign key to a time zone table, which resides in the same workspace as the network dataset and stores a list of time zones. The MSTimeZone field in the time zone table is also a foreign key, but to an entry in the Windows registry. (It's more common to see integer values as identifiers and foreign keys; however, the registry uses text to identify time zones.) The registry provides information to Network Analyst about the UTC offset and any date ranges for daylight saving time.
As shown in the graphic, you need a time zones table and a TimeZoneID field on your edge source feature classes before you can configure time zones on the network dataset. Once you have these components, you can create a time zone network attribute.
The following properties can be configured for the time zone attribute:
- Add Time Zone Attribute—Check this check box to use time zones while doing analysis.
- Time Zone Table—The drop-down list contains time zone tables that reside in the current network dataset's workspace. The time zone table is identified by the special field (MSTimeZone) in the table.
- Evaluators—Each attribute defined in the network must provide values for each source and direction (along and against for edges) participating in the network. An evaluator assigns values for the attribute of each source and travel direction, and a default evaluator for each element is used for those sources and directions that do not have an assigned evaluator for an attribute.
Configure the time zone attribute
To perform an analysis using time zones, the attribute needs to be configured on a network dataset. Follow the steps below to configure the time zone attribute:
- Access network attributes on the Network Dataset Properties dialog box.
- Click the Time Zone tab.
- Check the Add Time Zone Attribute check box.
- From the Time Zone Table drop-down list, choose the time zone table you want to use.
- In the Evaluators section, assign an evaluator to the source features.
- Click OK.
The time zone attribute is configured and saved to the network dataset.