Adding time zones to a network dataset

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 if time zones are ignored. To avoid these problems, you can design your network dataset to handle time zones.

This topic explains why configuring time zones on your network dataset may be necessary, and it describes how to configure them using a time zone network attribute.

Note:

When a network dataset falls entirely within a single time zone, you don't need to configure time zones. Also, configuring time zones is unnecessary if you never perform network analysis using a start time with a time-based impedance.

Why time zones are relevant to 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:13 a.m. a route analysis traverses two adjacent edges, starting from one edge in the eastern time zone and continuing along another in the central 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 central time zone for 7:13 a.m., it could retrieve the travel time for 8:13 a.m. or possibly some other time of the day, depending on what the default time zone is.

If time zones are configured properly, however, the cost of the edge in the eastern time zone is evaluated for 8:13 a.m. local time and the edge in the central time zone is correctly evaluated for 7:13 a.m. local time. The accuracy of travel times in a traffic-enabled network dataset is thus maintained. Also, directions show time zone changes.

The directions here show that a vehicle starts in one time zone at 8:00 a.m. and crosses into another at 8:13 a.m., which is 7:13 a.m. in the new time zone (step 7.1).

Irrespective of whether a network dataset that spans multiple time zones is traffic enabled or not, configuring a time zone attribute makes it easier to enter and interpret time-of-day properties—like 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 be 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 handles 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 or not 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 take care of 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.

Network Analyst 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 which 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.

In this diagram, streets with a TimeZoneID value of 2 are highlighted and related to the Central Standard Time record in the TimeZones table. The MSTimeZone value then relates the streets to the Central Standard Time key in the registry. These relationships allow Network Analyst to determine that these streets have a UTC offset of -6 hours from November to March and an offset of -5 from March to November.

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.

Creating the time zone table

To automatically create and populate a time zone table, run the Populate Time Zone Table tool, which you can download from the ArcGIS Resource Centers. Otherwise, the following steps will guide you through the process of manually creating a time zone table. For this sequence of steps and the next, it is assumed that you are familiar with creating and editing tables in ArcGIS.

Steps:

1. Create a table in the same workspace as the network dataset and give it a name, for example, TimeZones.

   If the workspace is a geodatabase, the table needs to be created at the geodatabase level even though the network dataset needs to reside one level deeper, that is, in a feature dataset.

2. Add a text attribute to the table and name it MSTimeZone.
   Caution:

   The name of the text attribute must be MSTimeZone since this is a keyword for Network Analyst.

   The length of the attribute needs to fit the name of the longest time zone that you will add to the table. As of March 2010, the longest time zone name in the Windows registry is 61 characters.

3. Optionally, add another text field to describe the time zone.

   More information about the benefits of adding a descriptive field like this is described in the next step.

4. Once the table is created, you need to populate the MSTimeZone field with time zone names. This can be done manually or programmatically.

   If you want to do this programmatically, search for the TimeZoneFactory object on the ArcGIS Resource Centers to get started. Otherwise, the substeps below describe how to manually look up the values in the Windows registry.

   1. Open the Registry Editor.

      In Windows 7 or Vista, click Start, type regedit in the Start Search text box, then press ENTER.

      In Windows XP, click Start > Run to open the Run dialog box. Type regedit into the Open text box and press ENTER.

   2. Keys in the registry look like folders. Expand the following keys: HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > WindowsNT > CurrentVersion > Time Zones.

      A long list of subordinate keys appears under the Time Zones key. Each key in the list represents a time zone. The values that you enter in your new time zone table under the MSTimeZone attribute must match the spelling of these key names exactly so that Network Analyst can find them in the registry at solve time.

      Caution:

      Make sure that you do not make any changes to the registry since this could corrupt your system.

      To copy a name, click a time zone key and press F2 to enter edit mode. Press CTRL+C to copy the name to the clipboard. Press ESC to exit edit mode. (To paste the name later, press CTRL+V.)

      When a key is selected in Registry Editor, its values appear on the other pane of the Registry Editor window. Together, the values describe the time zone, and Network Analyst uses the values to determine proper times. Although Network Analyst doesn't use the Display value, you can use that information to see the time zone's temporal offset from UTC and some geographic information about where it is used.

   3. Create a record in the time zone table for each time zone that you need to use in your network dataset. For each record's MSTimeZone field, enter or paste the name of the time zone as it appears in Registry Editor.

      For example, if your network dataset covers the contiguous United States, you would have five MSTimeZone values in your table, as shown below. (The Display field is optional.)

      ObjectID	MSTimeZone	Display
      1	Eastern Standard Time	(UTC-05:00) Eastern Time (US & Canada)
      2	Central Standard Time	(UTC-06:00) Central Time (US & Canada)
      3	Mountain Standard Time	(UTC-07:00) Mountain Time (US & Canada)
      4	US Mountain Standard Time	(UTC-07:00) Arizona
      5	Pacific Standard Time	(UTC-08:00) Pacific Time (US & Canada)

      Tip:

      The Display field is added here to better describe the MSTimeZone value. The information it contains was copied from the Display values of the time zone keys in the registry.

      Although Network Analyst doesn't require a field like Display in the table, adding it can make identifying the time zones represented by MSTimeZone easier for you and other users. For example, the Mountain Standard Time and US Mountain Standard Time values for MSTimeZone look very similar. From the Display field, however, you can see that Arizona's time zone is represented by US Mountain Standard Time. (Arizona needs a separate time zone identifier because, unlike the rest of the states in mountain time, it doesn't observe daylight saving time.)

Now you have a table with a text field named MSTimeZone. The next step is to relate each edge source feature to the correct time zone in the table.

Adding the TimeZoneID field

Each edge source feature needs to be associated with precisely one time zone.

Steps:

1. Add an integer field named TimeZoneID to each edge source feature class. Although you can assign any name to this field, TimeZoneID is common.
2. Calculate the values of the edge source features.

   The TimeZoneID values are foreign keys that relate the features to records in the time zone table that you just created. So in the example above, ObjectID 5 represents Pacific standard time, so all edge source features in that time zone would need a TimeZoneID value of 5. If Pacific standard time happened to have a different ObjectID value, you would populate TimeZoneID with that value instead.

Adding a time zone network attribute

This set of steps demonstrates how to create a time zone network attribute on the network dataset. The attribute makes the relationship between the TimeZoneID field in the edge source feature classes and the time zone table.

Steps:

1. On the Attributes tab of the Network Dataset Properties dialog box or the New Network Dataset wizard, click Add.

   The Add New Attribute dialog box opens.

2. Type a name for the attribute, such as TimeZone.
3. Choose Descriptor from the Usage Type list.
4. Choose Integer from the Data Type list.

   

5. Click OK.

   The attribute is added to the list of attributes.

6. Right-click the new attribute, click Use Time Zones, then click the name of the time zone table that you created.

   A green circle with a T in the middle appears to the left of the attribute name, which indicates it is the time zone attribute.

7. Double-click the time zone attribute name to open the Evaluators dialog box.
8. For each edge source, set up a field evaluator to read the TimeZoneID values from the source feature classes.

   In the example below, a field evaluator that reads values from a TimeZoneID field in the Streets source feature class is assigned to both the from–to and to–from directions.

9. Click OK.

   The Evaluators dialog box closes. After completing the New Network Dataset wizard or closing the Network Dataset Properties dialog box, you can build the network dataset to incorporate the new time zone field.