You can store temporal data in a variety of ways. Here are some best practices you can follow when storing your temporal data.
Store time stamps in a date field
It is recommended that you store the time stamps of your temporal data in a 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.
If a 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. 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 choose to use the Convert Time 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 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 choose to 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 where 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.