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.
Depending on your needs, you can also 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.
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 ArcGIS Pro, store the time values associated with individual features in a row format. Each feature or row in a table can have either time values in one field representing a time instant or time values in two fields representing the 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. To visualize this data through time, 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 current 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 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.