Extended Date Time Format
Official Web Site  

Problem, Requirements, and Basic Approach

 

Statement of the Problem

No standard date/time format meets the needs of XML metadata schemas. W3C XML Schema built-in types xs:date [1], xs:time [2], and xs:dateTime [3] are inadequate, as is W3CDTF [4], and TEMPER [5].

  • The string 2001-02-03, for example, is a valid xs:date value, but 20010203 (without the hyphens) is not, even though it is a valid ISO 8601 [6] date. This is a choice that W3C made when defining xs:date: the hyphenated form was chosen and the non-hyphenated form excluded.
  • Similarly, for xs:dateTime, 2001-02-03T09:30:01 is valid, but  2001-02-03T093001 (without the colons in the time) is not, even thought it is a valid ISO 8601 date/time.
  • xs:date does not allow just the year and month (without the day), or just the year. ISO 8601 supports these. Examples: "2008-12", "2008".
  • xs:date does not allow a date range (for example "1964/2008"). ISO 8601 does.

Many dates are coded in database records without hyphens (conformant with ISO 8601). When extracting a date from a database record to insert into an XML record, some implementors feel it is an unnecessary burden to have to insert hyphens.  Times are often encoded without colons.  Year/month (without the day) needs to be represented, as do date ranges. 

And there are additional requirements that extend even beyond ISO 8601.

Requirements

This is a partial list of known requirements; it is not claimed to be complete, but it is the set of requirements that the current schema addresses. Proposals for additional requirements are welcome.

  1. The "basic" option in ISO 8601, i.e. YYYYMMDD without hyphens, and HHMMSS without colons.
  2. BC dates. For example '-1000' for "the year 1000 BC"
  3. Time zones. For example, '-05:00' to represent "five hours earlier than UTC" (i.e. US Eastern).
  4. Year and month only (no day of month). For example, '2004-04' would mean "April of 2004". Or year only.
  5. Questionable dates. E.g. 1992? would mean "possibly" the year 1992, but not "definitely".
  6. Approximate dates. E.g. 1992~ would mean "approximately" the year 1992.
  7. Uncertain dates. E.g. 199? would mean some year in the 1990s, but not certain which year; 1999-?? would mean some month in 1999, 199901?? would mean some day in the month of 1999-01.
  8. Date range (start and end).
  9. End date “open” in a date range.
  10. Start and/or end date "unknown" in a date range.

Basic Approach

The proposed basic approach is to develop a definition which is  both a profile of and  extension to ISO 8601.  

  • A profile, because:
    • It would include relevant/necessary features of 8601 only, discarding unnecessary features; and
    • It would prescribe these features in a manner compatible with 8601.
  • An Extension, because:
    • It would not, strictly speaking, be a profile of 8601, since it would include features that are not in 8601.  So in this sense it would extend 8601.  

When the definition matures it may be incorporated into schemas such as MODS and METS. (It is already in use within the PREMIS schema.)

At some point it may be proposed for standardization, perhaps within a future version of ISO 8601. Keeping the specification as compatible as possible with ISO 8601 increases the likelihood that the extensions will be taken seriously. The definition might be proposed to W3C for adoption as an XML schema type; the benefits of this are clear, among them, strict validation would be supported.  

 edtf home »Problem, Requirements, and Basic Approach