Standards
ISO 8601 date and time representation
A standard for representing dates, times, intervals, and related temporal values.
- Kind
- Formats
- Steward
- International Organization for Standardization (ISO)
- Official source
- https://www.iso.org/iso-8601-date-and-time-format.html
What it describes
ISO 8601 defines machine-readable representations for dates and times, including calendar dates, times with offsets, and intervals. Consistent notation reduces ambiguity between date orders such as day-month-year and month-day-year. It is useful in records that combine sources from different regions. Syntax still has to match the temporal meaning of the field: a date is not the same kind of value as an instant.
An offset does not name a time zone or its historical daylight-saving rules, and a timestamp does not by itself state when a fact was valid in the world. Store the source's temporal precision and relevant zone separately where needed. For reproducible records, distinguish event time, valid time, and observation or transaction time rather than placing all three meanings into one date field.
Structure
Defined date, time, date-time, interval, and duration representations; extended calendar dates commonly use YYYY-MM-DD.
Useful for
- Exchange dates without locale ambiguity.
- Preserve temporal precision.
- Support point-in-time comparisons.
Limits
- An offset is not a named time zone.
- A date is not an instant.
- Syntax does not decide temporal semantics.
How it is used in practice
ISO 8601 is why a date can be written 2024-03-14 and read the same way in every locale. It specifies calendar dates, ordinal and week dates, times of day, combined date-time values, time zone offsets, durations and intervals. Programming languages, databases and interchange formats borrow from it. Two widely used profiles narrow it to what Internet protocols and web documents need: RFC 3339 and a W3C note on date and time formats. Database systems document how their timestamp types parse and print ISO-style strings.
The format is the least of the problem. The real work is deciding what a given timestamp means: when something happened, when it was recorded, when it applied, or when it was published. A well-formed string answers none of those.
A worked example
A fictional regulatory notice is dated 2024-03-14 and says a restriction takes effect "from 1 July". A database stores 2024-03-14T00:00:00Z in a field called date. A reviewer reading the database later cannot tell whether the date is the notice date, the effective date or the time the row was loaded.
A better record has separate fields. The notice's publication date is a date without time, since the source gives no time. The effective date is a date, 2024-07-01, with the jurisdiction's time zone noted because the restriction takes effect at a local midnight. The ingestion time is a timestamp with an offset, recorded by the system. The reviewer can now answer the question "what did we know on 20 March" by filtering on ingestion time, and "what applied on 15 July" by filtering on the effective date. The two answers are different and both are reproducible.
Evaluating a claim that rests on a timestamp
Ask what the timestamp measures. Ask about its precision: a date is not a midnight instant, and storing it as one invites a one-day error when it is converted to another time zone. Ask about the zone: an offset such as +01:00 is a fixed difference from UTC, while a named zone carries the rules for daylight saving, which change over history and between places.
Ask whether the value is a source's statement or a system's observation. A date printed in a document is evidence of what the document says. A system timestamp is evidence of when the system acted. Mixing them in one column removes the ability to reason about delay, correction and late arrival. For reproducibility, keep the original string as received alongside the parsed value.
Confusions to avoid
ISO 8601 is a family of representations, and parsers differ in which they accept. Some accept a space instead of the T separator, some reject week dates, some treat a missing offset as local time and others as UTC. A pipeline that depends on these defaults will behave differently on another machine. State the profile in use.
It is also not a time-zone database and not a model of validity. It cannot say that a fact held between two dates and was recorded on a third. For that, a bitemporal design with valid time and transaction time is needed, and ISO 8601 only supplies the notation for the values.
Questions a reviewer can ask
What does each date or timestamp mean: event, effective, recorded or published? Is the precision stated, so that a date is not treated as an instant? Is the time zone a named zone or a fixed offset, and does it matter for the claim? Which profile of the standard does the parser accept? Is the original string retained next to the parsed value? Can the past state be reproduced by filtering on the recorded time?
Related terms
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Which of your sources carry ISO 8601 date and time representation?
Tell us which sources carry it, which key the same entity some other way and who may read which. We reply with whether and how a first record would use this format.
Or write to [email protected] in your own words.