Element Description
The Temporal Extents element describes when data were acquired or collected.
Best Practices
Dates provided in CMR metadata should comply with the ISO 8601 Standard, which is an International Standard for the representation of dates and times.
The Data Product Development Guide for Data Producers offers the following guidance about time:
"The CF Conventions represent time as an integer or float, with the units attribute set to the time
unit since an epochal time, represented as YYYY-MM-DDThh:mm:ss (e.g., “seconds since 1993-01-
01T00:00:00Z”). Unless there is a strongly justifiable reason not to do so, use the UTC Time Zone
instead of alternative time zones.The date-time information in the file should adhere to the following guidelines (detailed in [26], Rec.
3.11):• Adopt the ISO 8601 standard [51] [52] for date-time information representation.
• If describing time intervals, the start time should appear before the end time.
• Date-time fields representing the temporal extent of a file’s data should appear before any
other date-time field in the file name.• All date-time fields should have the same format."
There are three options in the UMM for describing the temporal extent of data: Single Date Time, Range Date Time and Periodic Date Time.
Using different temporal extent representations between collection and granule level metadata are allowed, as long as it makes logical sense. For example, Single Date Time could be used to describe temporal coverage at the granule level, whereas a Range Date Time may be used to describe temporal coverage at the collection level. It is important that the temporal extent at the collection level be in sync with the temporal extent provided in associated granule level metadata files.
Single Date Time
The Single Date Time element should be used if data were captured instantaneously (i.e. a single time stamp sufficiently describes the temporal extent of the data). For example, if a data file contains an image that was taken by a camera, the time stamp associated with the time the image was taken would be listed as the Single Date Time in the granule level metadata. Single Date Time may also be used in the collection level metadata if appropriate. If the exact time of data capture is known, it is strongly recommended that the time be included in the Single Date Time. If the exact time of data collection is unknown, it is okay to just provide a date. Multiple Single Date Times may be provided if necessary (cardinality 0..*).
Examples:
SingleDateTime: 2018-11-11T14:53:32Z
SingleDateTime: 2017-04-14T05:26:22Z
Range Date Time
The Range Date Time element should be used when a continuous time range is appropriate to describe the temporal extent of data. Range Date Time is composed of two sub-elements: Beginning Date Time and Ending Date Time, which describe the start and end time of a data file or a collection.
For completed datasets:
- It is required that an Ending Date Time be provided. The 'EndingDateTime' element should specify the ending date and time of the last available granule in the collection. In addition:
- The ‘Ends at Present Flag' element should be set to “false.” Setting the ‘Ends at Present Flag’ element to “false” tells the CMR that the ending time for the collection is in the past. Note: Ends at Present Flag is an optional element.
- The Collection Progress element should be set to “COMPLETE”
If data collection is ongoing,
- An Ending Date Time does not need to be provided. Even if the future end date of the collection is known, this future date should not be provided in the metadata as the Ending Date Time, since data for these future dates do not yet exist. In addition:
- The ‘Ends at Present Flag’ element should be set to “true.” Setting the ‘Ends at Present Flag’ element to “true” tells the CMR that the ending time for the collection is present day, and thus eliminates the need to specify the Ending Date Time of the collection. This also eliminates the need to update the Ending Date Time in the metadata each time new data gets added to the collection.
- The Collection Progress element should be set to “ACTIVE”
Multiple RangeDateTimes may be provided if necessary (cardinality 0..*). It is recommended that multiple RangeDateTimes be used if there is a significant temporal gap present in the data. Generally, the Ending Date Time provided should not be in the future, with the exception of data that has an an actual future time stamp (e.g. modeled/ forecasted data that includes future projections).
Examples:
A satellite collected data from May 1, 2004 to February 10, 2008. A data product derived from this satellite provides monthly global averages of surface temperature. A monthly global average for February 2008 was not included in the dataset since only 10 days of data were available in February.
RangeDateTime for the collection: | RangeDateTime for the first granule in the collection: |
---|---|
BeginningDateTime: 2004-05-01T00:00:00Z EndingDateTime: 2008-01-31T23:59:59Z | BeginningDateTime: 2004-05-01T00:00:00Z EndingDateTime: 2004-05-31T23:59:59Z |
Radar measurements were taken from a plane. One flight occurred each day from August 20, 2018 to August 31, 2018.
RangeDateTime for the collection: | RangeDateTime for the first granule in the collection: | RangeDateTime for the last granule in the collection: |
---|---|---|
BeginningDateTime: 2018-08-20T12:34:00Z EndingDateTime: 2018-08-31T10:01:02Z | BeginningDateTime: 2018-08-20T12:34:00Z EndingDateTime: 2018-08-20T16:50:52Z | BeginningDateTime: 2018-08-31T06:18:21Z EndingDateTime: 2018-08-31T10:01:02Z |
Periodic Date Time
For data that is collected in regular reoccurring intervals, the temporal extent can be described as a Periodic Date Time. Periodic Date Time is described via the below sub-elements. If Periodic Date Time is provided, all sub-elements are required:
Name: The name given to the recurring time period.
StartDate: The date (day and time) of the first occurrence of this regularly occurring period. This is when data collections begins for the entire collection. This also identifies the day of the month and time of the day when data collection starts for each reoccurring cycle.
EndDate: The date (day and time) of the last occurrence of this regularly occurring period. This is when data collection ends for the entire collection.
DurationUnit: The unit for the regularly reoccurring data collection period. In combination with DurationValue, this describes the length of time that data gets collected. This value must be selected from a controlled vocabulary list maintained in the UMM-Common schema. Options include: DAY, MONTH, YEAR
DurationValue: The number of DurationUnits comprising the regularly reoccurring data collection period. Together, DurationValue and DurationUnit describe the length of time that data gets collected.
PeriodCycleDurationUnit: The duration unit of one full cycle. The full cycle includes both the active data collection period as well as an inactive period. This value must be selected from a controlled vocabulary list maintained in the UMM-Common schema. Options include: DAY, MONTH, YEAR.
PeriodCycleDurationValue: The number of CycleDurationUnits comprising one full cycle. Together, CycleDurationValue and CycleDurationUnit describe the length of a full cycle which includes both the active data collection period as well as an inactive period.
Examples:
Data for a field campaign are collected in December, January and February of each year. Data collection started in December 2013 and ended in February 2017.
Name: Winter_FieldCampaign
StartDate: 2013-12-01T00:00:00Z
EndDate: 2017-02-28T23:59:59Z
DurationUnit: MONTH
DurationValue: 3
PeriodCycleDurationUnit: YEAR
PeriodCycleDurationValue: 1
A sensor collected data every morning from 5 AM to 6 AM UTC.
Name: AM_Sensor_Daily
StartDate: 2000-04-01T05:00:00Z
EndDate: 2010-09-04T06:00:00Z
DurationUnit: DAY
DurationValue: 0.0417
PeriodCycleDurationUnit: DAY
PeriodCycleDurationValue: 1
For paleoclimate or geologic data, temporal coverage can be described via the Paleo Temporal Coverage elements. Paleo Temporal Coverage should be used to describe time frames earlier than 0001-01-01 (yyyy-mm-dd). Please see the Paleo Temporal Coverage wiki page for details.
Element Specification
Model | Element | Type | Constraints | Required? | Cardinality | Notes |
---|---|---|---|---|---|---|
UMM-Common | TemporalExtents/PrecisionOfSeconds | Integer | n/a | No | 0..1 | The precision (position in number of places to right of decimal point) of seconds used in measurement. |
UMM-Common | TemporalExtents/EndsAtPresentFlag | Boolean | n/a | No | 0..1 | Setting the Ends At Present Flag to 'True' indicates that a data collection currently ends at the present date. Setting the Ends at Present flag to 'True' eliminates the need to continuously update the Range Ending Time for collections where granules are continuously being added to the collection inventory. |
UMM-Common | TemporalExtents/TemporalResolution | Object | n/a | No | 0..1 | |
UMM-Common | TemporalExtents/TemporalResolution/Unit | Enumeration | Valid Values: "Constant", "Varies", "Second", "Minute", "Hour", "Day", "Week", "Month", "Year", "Diurnal" | Yes | 1 | |
UMM-Common | TemporalExtents/TemporalResolution/Value | Number | n/a | Yes if Type=Constant or Varies | 0..1 | Number may include decimal points 3.14 vs Integers such as 42 |
Choice of:
(1) SingleDateTime
If SingleDateTime is selected, the cardinality is 1..*
Model | Element | Type | Constraints | Required? | Cardinality | Notes |
---|---|---|---|---|---|---|
UMM-Common | TemporalExtents/SingleDateTime | dateTime | n/a | Yes, if applicable | 1 | Dates must comply with the ISO 8601 Standard. |
(2) RangeDateTime
If RangeDateTime is selected, the cardinality is 1..*
Model | Element | Type | Constraints | Required? | Cardinality | Notes |
---|---|---|---|---|---|---|
UMM-Common | TemporalExtents/RangeDateTime/BeginningDateTime | dateTime | n/a | Yes, if applicable | 1 | Dates must comply with the ISO 8601 Standard. |
UMM-Common | TemporalExtents/RangeDateTime/EndingDateTime | dateTime | n/a | No | 0..1 | An EndingDateTime must be provided at the collection level if the collection is complete. |
(3) PeriodicDateTime
If PeriodicDateTime is selected, the cardinality is 1..*
Model | Element | Type | Usable Valid Values | Constraints | Required? | Cardinality | Notes |
---|---|---|---|---|---|---|---|
UMM-Common | TemporalExtents/PeriodicDateTime/Name | String | n/a | 1 - 30 characters | Yes, if applicable | 1 | |
UMM-Common | TemporalExtents/PeriodicDateTime/StartDate | dateTime | n/a | n/a | Yes, if applicable | 1 | Dates must comply with the ISO 8601 Standard. |
UMM-Common | TemporalExtents/PeriodicDateTime/EndDate | dateTime | n/a | n/a | Yes, if applicable | 1 | Dates must comply with the ISO 8601 Standard. |
UMM-Common | TemporalExtents/PeriodicDateTime/DurationUnit | Enumeration | DAY MONTH YEAR | n/a | Yes, if applicable | 1 | |
UMM-Common | TemporalExtents/PeriodicDateTime/DurationValue | Integer | n/a | n/a | Yes, if applicable | 1 | |
UMM-Common | TemporalExtents/PeriodicDateTime/PeriodCycleDurationUnit | Enumeration | DAY MONTH YEAR | n/a | Yes, if applicable | 1 | |
UMM-Common | TemporalExtents/PeriodicDateTime/PeriodCycleDurationValue | Integer | n/a | n/a | Yes, if applicable | 1 |
Metadata Validation and QA/QC
All metadata entering the CMR goes through the below process to ensure metadata quality requirements are met. All records undergo CMR validation before entering the system. The process of QA/QC is slightly different for NASA and non-NASA data providers. Non-NASA providers include interagency and international data providers and are referred to as the International Directory Network (IDN).
Please see the expandable sections below for flowchart details.
Dialect Mappings
UMM Migration
None
History
UMM Versioning
Version | Date | What Changed |
---|---|---|
1.18.0 | 2024-03-18 | Added Temporal Resolution to Temporal Extents in version 1.18.0 |
1.17.1 | 2022-08-10 | No changes were made for Temporal Extents during the transition from version 1.17 to 1.17.1 |
1.17 | 2022-05-11 | No changes were made for Temporal Extents during the transition from version 1.16.7 to 1.17 |
1.16.7 | 2022-03-02 | No changes were made for Temporal Extents during the transition from version 1.16.6 to 1.16.7 |
1.16.6 | 2021-12-01 | No changes were made for Temporal Extents during the transition from version 1.16.5 to 1.16.6 |
1.16.5 | 2021-07-13 | No changes were made for Temporal Extents during the transition from version 1.16.4 to 1.16.5 |
1.16.4 | 2021-06-30 | No changes were made for Temporal Extents during the transition from version 1.16.3 to 1.16.4 |
1.16.3 | 2021-05-19 | No changes were made for Temporal Extents during the transition from version 1.16.2 to 1.16.3 |
1.16.2 | 2021-04-07 | No changes were made for Temporal Extents during the transition from version 1.16.1 to 1.16.2 |
1.16.1 | 2021-04-07 | No changes were made for Temporal Extents during the transition from version 1.16 to 1.16.1 |
1.16 | 2021-03-24 | No changes were made for Temporal Extents during the transition from version 1.15.5 to 1.16 |
1.15.5 | 2020-12-03 | No changes were made for Temporal Extents during the transition from version 1.15.4 to 1.15.5 |
1.15.4 | 2020-09-18 | No changes were made for Temporal Extents during the transition from version 1.15.3 to 1.15.4 |
1.15.3 | 2020-07-01 | No changes were made for Temporal Extents during the transition from version 1.15.2 to 1.15.3 |
1.15.2 | 2020-05-20 | No changes were made for Temporal Extents during the transition from version 1.15.1 to 1.15.2 |
1.15.1 | 2020-03-25 | No changes were made for Temporal Extents during the transition from version 1.15.0 to 1.15.1 |
1.15.0 | 2020-02-26 | No changes were made for Temporal Extents during the transition from version 1.14.0 to 1.15.0 |
1.14.0 | 2019-10-21 | No changes were made for Temporal Extents during the transition from version 1.13.0 to 1.14.0 |
1.13.0 | 2019-04-11 | No changes were made for Temporal Extents during the transition from version 1.12.0 to 1.13.0 |
1.12.0 | 2019-01-22 | No changes were made for Temporal Extents during the transition from version 1.11.0 to 1.12.0. |
1.11.0 | 2018-11-28 | No changes were made for Temporal Extents during the transition from version 1.10.0 to 1.11.0. |
1.10.0 | 2018-05-02 | In the transition from Version 1.9 to 10.0, the subelement 'Temporal Range Type' was removed from Temporal Extent Type. |
ARC Documentation
Version | Date | What Changed | Author |
---|---|---|---|
1.0 | 2018-08-17 | Recommendations/priority matrix transferred from internal ARC documentation to wiki space |