Core Data Model Mapping Directory

Date Time

A date designating a point in time.

Dates recorded within public sector data sets exist in many different formats. In order to make those dates interoperable, it is important that they should be represented in a regular manner wherever possible. The most widely used date formats are those that conform to ISO 8601:2004 [ISO 8601] of which the relevant XML Datatypes [XSD] are a subset. Dates should be recorded as formatted strings that are conformant with that standard with the relevant data type declaration. Known dates are recorded as literals in the form yyyy-mm-dd and then typed as xsd:date. Where the full date and time are both known, and this can be important in records of death for example, use the xsd:dateTime format of yyyy-mm-ddThh:mm:ss with or without timezone information. Where just a year is known use xsd:gYear (yyyy) and where just the month is known use xsd:gYearMonth (yyyy-mm). The 'g' is for Gregorian. Non-Gregorian dates are not covered by XSD. For emphasis, the datatype should be explicitly stated so that software can correctly interpret the data. If a date is provided in a string that is conformant with a standard other than XSD, and that is not covered by XSD, then it should be typed accordingly. It should also be noted that the UK Government provides a URI scheme for time intervals that may be useful [DGUT] and that 8601:2004 itself allows intervals to be defined. In some public sector data sets, full dates are not always known. For example, dates such as "some time in the 1920s" or "between 1925 and 1932" are not uncommon. There is no agreed formal way to record such uncertainty dates and therefore an un-typed plain string should be used. In other words, a string like "between 1925 and 1932" cannot be improved upon. To use an interval as the value for, say, a date of birth, is incorrect, The date of birth is not the time interval that began in 1925 and ended in 1932, rather, it was an instant some time during that period. There is an important difference between declaring that an event occurred throughout a time interval and that it occurred at an unknown instant within a time interval. Some data sets use other methods to express uncertainty such as using false dates. Sometimes '00' or '??' is used to indicate uncertainty so that "August 1986" might be recorded as either 1986-00-00 or 1986-00-??. This practice is unnecessary and strongly discouraged, particularly if such dates are typed as XSD dates. If a string such as 1986-08-00 is fed to software expecting an xsd:date then it will either reject the data, in which case data is lost, or it might convert it to the nearest actual date 1986-08-01. In the latter case, the accurate yet imprecise date of "August 1986" has now been converted to a more precise date of 1st August 1986 that may be anything up to 30 days wide of the truth.

Internal Identifier
No internal identifier
Public ID
http://mapping.semic.eu/vdm/id/cv/8cf10d2341ed01492506085688270c1e
CDMMD ID
No CDMMD Id
Type
Datatype
Raw data
HTML | RDF/XML | Turtle

Metadata

type Datatype
label Date Time
Title Date Time
definition A date designating a point in time.
Description Dates recorded within public sector data sets exist in many different formats. In order to make those dates interoperable, it is important that they should be represented in a regular manner wherever possible. The most widely used date formats are those that conform to ISO 8601:2004 [ISO 8601] of which the relevant XML Datatypes [XSD] are a subset. Dates should be recorded as formatted strings that are conformant with that standard with the relevant data type declaration. Known dates are recorded as literals in the form yyyy-mm-dd and then typed as xsd:date. Where the full date and time are both known, and this can be important in records of death for example, use the xsd:dateTime format of yyyy-mm-ddThh:mm:ss with or without timezone information. Where just a year is known use xsd:gYear (yyyy) and where just the month is known use xsd:gYearMonth (yyyy-mm). The 'g' is for Gregorian. Non-Gregorian dates are not covered by XSD. For emphasis, the datatype should be explicitly stated so that software can correctly interpret the data. If a date is provided in a string that is conformant with a standard other than XSD, and that is not covered by XSD, then it should be typed accordingly. It should also be noted that the UK Government provides a URI scheme for time intervals that may be useful [DGUT] and that 8601:2004 itself allows intervals to be defined. In some public sector data sets, full dates are not always known. For example, dates such as "some time in the 1920s" or "between 1925 and 1932" are not uncommon. There is no agreed formal way to record such uncertainty dates and therefore an un-typed plain string should be used. In other words, a string like "between 1925 and 1932" cannot be improved upon. To use an interval as the value for, say, a date of birth, is incorrect, The date of birth is not the time interval that began in 1925 and ended in 1932, rather, it was an instant some time during that period. There is an important difference between declaring that an event occurred throughout a time interval and that it occurred at an unknown instant within a time interval. Some data sets use other methods to express uncertainty such as using false dates. Sometimes '00' or '??' is used to indicate uncertainty so that "August 1986" might be recorded as either 1986-00-00 or 1986-00-??. This practice is unnecessary and strongly discouraged, particularly if such dates are typed as XSD dates. If a string such as 1986-08-00 is fed to software expecting an xsd:date then it will either reject the data, in which case data is lost, or it might convert it to the nearest actual date 1986-08-01. In the latter case, the accurate yet imprecise date of "August 1986" has now been converted to a more precise date of 1st August 1986 that may be anything up to 30 days wide of the truth.
Type Datatype
http://mapping.semic.eu/def#dataType Date Time
sample

Mappings

Mapping Type Element Core Data Model
has close match nc:DateType NIEM 3.0
has exact match 147bcdf19c4cf843a6408c3099a4b1c5
has exact match 15aedd586a540638ff886319d303d3f3
has exact match f8039b4601b5ca18f68e68b58add6453

Referenced by

Date Of Birth (PersonDateOfBirth)
Date Of Death (PersonDateOfDeath)
listing date (dcat:CatalogRecord/dct:issued)
Release Date (dcat:Catalog/dct:issued)
release date (dcat:Dataset/dct:issued)
Release Date (dcat:Distribution/dct:issued)
update/modification date (dcat:Catalog/dct:modified)
update/modification date (dcat:Dataset/dct:modified)
update/modification date (dcat:Distribution/dct:modified)