Best practices for storing temporal data

You can store temporal data in a variety of ways. Here are best practices you can follow when storing temporal data.

Store time stamps in a date field

It is recommended that you store the time stamps of your temporal data in a dedicated date field. This is a database field type specifically for storing time and date information. It is most efficient for query performance and supports more sophisticated database queries than when storing time in a numeric or string field. Depending on your data source, the available date field types include Date, DateOnly, TimeOnly, and TimestampOffset.

If a dedicated date field cannot be used, you can store the time stamps in your data in string or numeric fields. For example, you can store yearly data as 2000, 2001, and so on, or you can store a full date time value such as 2015-07-04T13:11:26.002, which uses ISO-8601 styling. For string fields, the need for efficient querying and sorting means that the text values must list the time unit values from largest to smallest, such as 20120126 for January 26, 2012.

Note:

Date display is only supported for the range of AD100 to AD10,000. To work with dates outside this range, it is recommended that you convert your values into either a numeric format (and filter using the range slider) or a string format (for labeling).

You can use the Convert Temporal Field geoprocessing tool to convert a string or numeric field containing time stamps into a date field.

Store temporal data in a row format

If you're using temporal data in ArcGIS AllSource, store the time values associated with individual features in a row format. You can use the time slider to navigate through your data in time, and the time slider filters the display based on the layer to only show the rows within a specified duration of time.

Each feature or row in a table can have either time values in one field representing a moment in time or time values in two fields representing a duration in time with a beginning and end of the observation.

Depending on whether the attributes of your data change over time or the shape of each feature changes over time, you can store your temporal data in a single table or in separate tables.

Often you'll have time represented in columns in your attribute table. For instance, medical costs per county for 1990, 1991, and 1992 might be listed in separate columns in a single row in the table. To visualize this data through time using the time slider's capabilities for data filtering, you must reformat the table so that the time values are in row format.

Index fields that contain time values

To improve time visualization and query performance, it is recommended that you index the fields containing the time values. You can use the Add Attribute Index geoprocessing tool to add an index to a field in an existing table or feature class.

Use standard time

For temporal data collected in regions where time is adjusted for daylight saving time, you should store the time values in your data in standard time. Data collected with daylight saving time can be difficult to maintain. Daylight saving can vary from region to region, and the rules defining the daylight saving adjustments can change over time.

Storing the time values in standard time prevents any loss or overlaps of data during data compilation and allows time visualization during the transition hours without ambiguity.

Use null values in a time field

There are instances in which a null value is stored in a time field. For example, a layer with both start and end times can indicate that a feature is considered to exist into the future by using a null end time. Then as the time slider is played, the feature appears when the start time is included and it continues to display through the remaining playback. The same can be said in reverse; a null start time indicates that the feature exists into the past and immediately displays from the start until the end time has been reached.

However, when time is stored in a single field, a feature with a null value is excluded, as it cannot fall within a time span.

Determine which date field type to use

How you store your data, as well as how you plan to use the date, directly impact which date and time field types are recommended. It is important to choose the best one for your needs. There are four types of date fields available: Date, DateOnly, TimeOnly, and TimestampOffset.

The following table details considerations worth noting when determining which date field type to use:

Date field type	What it contains	How the time zone is defined	What it is well suited for
Date	Both the date and time	When the layer is made time-aware, a time zone can be defined for the layer, thereby defining its absolute position in time. All values in the field are assumed to be in the same time zone.	Time values that are either all in UTC (Example 1) or all within the same local time zone (Example 2). Example 1: A scientific group capturing lightning strike data from around the planet. Example 2: A local government storing the dates and times of when restaurants in its county were last inspected for cleanliness.
DateOnly Legacy: This format was introduced at ArcGIS Pro 3.2.	The date component only	When the layer is made time-aware, the layer will operate with the time zone set to None. This means that the date part of the time slider, regardless of the time zone of the map, will be used to filter and display content. Note: A single day in a DateOnly field is effectively a 24-hour duration, so rows will be shown even when the time slider is filtering for part of that day.	Data that was captured in the granularity of days or where something applies to, or represents, the entire day. Example 1: Historians working with the inauguration dates of world leaders. Example 2: A scientific group monitoring the maximum daily air temperature from cities around the planet.
TimeOnly Legacy: This format was introduced at ArcGIS Pro 3.2.	The time component only	Layers using a TimeOnly field cannot be made time-aware.	Data that repeats daily or content in which only the time component matters. Example 1: A zoo managing the daily routine of feeding its animals. Example 2: A secure facility that tracks the unlocking of gates and doors on a fixed daily schedule.
TimestampOffset Legacy: This format was introduced at ArcGIS Pro 3.2.	The date, time, and relative time zone offset from UTC	As the time zone offset value is already stored with the value in each cell, there is no option to choose a named time zone for the layer. Each value in the table can use a different time offset. Note: The offset time in hours indicates its temporal offset from UTC, rather than a named time zone, such as Pacific Standard Time. As multiple named time zones can share the same temporal offset, the storage is not a specific time zone with additional awareness of daylight saving or historical changes.	Time values where the dates cross multiple time zones and the local time value is important. Example 1: An airline managing its takeoff and landing schedules in absolute time around the world, while also understanding the local time for passengers. Example 2: A study on the cost of earthquakes that works with events in absolute time while also capturing the local time the residents experienced it.