{"concept_id":"ALTSS-DATA-013","slug":"bitemporal-data","canonical_name":"Bitemporal Data","aliases":["bitemporal","valid time and transaction time"],"kind":"term","authority":"academic","facets":["EVD"],"domains":["DATA-OSINT"],"display_title":"Bitemporal Data","search_aliases":["what is bitemporal data","bitemporal vs temporal table","system versioned table","valid time transaction time example","bitemporal modeling"],"one_sentence_definition":"Bitemporal data is a record of facts kept on two independent time axes: valid time, when each fact was true in the world, and transaction time, when the database held that version of it.","plain_english":"A bitemporal record can answer \"what did we believe on date K about date S?\". When a fact changes in the world, a new valid period starts. When the record is corrected, a new version is added with the same valid period and a later transaction time. Nothing is overwritten, so the history of the world and the history of what was known are both kept.","formal_definition":"Snodgrass defines valid time as when a fact was true in reality and transaction time as when it was stored in the database; a table supporting both is bitemporal. The 2011 edition of the Structured Query Language (SQL) standard, SQL:2011, allows one table to be both an application-time period table (valid time) and a system-versioned table (transaction time); the standard does not itself use the word \"bitemporal\", which comes from the literature.","parent_concepts":[],"child_concepts":[],"related_concepts":["temporal-validity","point-in-time-data","evidence-dates","data-provenance","data-freshness"],"comparison_concepts":[],"not_the_same_as":[{"slug":"temporal-validity","distinction":"Temporal validity is the valid-time axis alone; bitemporal data adds transaction time, so a correction stays distinguishable from a change."},{"slug":"point-in-time-data","distinction":"Point-in-time data is the use case (reproducing what was known); bitemporal storage is one way to provide it."},{"slug":"data-provenance","distinction":"Data provenance records where a value came from and how it was produced, including the audit trail of changes to the record; bitemporal data adds when each fact was true in the world."}],"formula_ids":[],"worked_examples":[{"title":"Illustrative chief investment officer change recorded late","paragraphs":["| Version | Holder | Valid time | Transaction time |\n|---|---|---|---|\n| v1 | Person A | [1 Jan 2019, end unknown) | [15 Jan 2019, 10 Sep 2024) |\n| v2 | Person A | [1 Jan 2019, 1 Jul 2024) | [10 Sep 2024, current) |\n| v3 | Person B | [1 Jul 2024, end unknown) | [10 Sep 2024, current) |","On 10 September 2024 the plan's published minutes show that A left on 30 June and B started on 1 July. v1 is closed in transaction time and v2 and v3 are added.","- \"Who was CIO on 15 August 2024, as recorded on 1 September 2024?\" returns **A**: that was the record then.\n- \"Who was CIO on 15 August 2024, as recorded today?\" returns **B**.","Both answers are correct for their question, and both remain retrievable."]}],"sections":[{"heading":"Two axes, set by different parties","paragraphs":["- **Valid time** (application time) is supplied by the user from evidence: effective dates, completion dates, as-of dates. It can be in the past, present or future and can be corrected.\n- **Transaction time** (system time) is set by the database. In SQL:2011 system-versioned tables, users cannot assign or change it; an insert sets the start to the transaction time stamp, and an update or delete closes the current row and keeps it as a historical row. Kulkarni and Michels note that this guarantees the recorded history of changes cannot be tampered with, which matters for audit and compliance.","Transaction time is not the date a source was captured. A document captured on Monday and loaded on Wednesday has a Monday capture date (an [evidence date](/glossary/evidence-dates)) and a Wednesday transaction time."]},{"heading":"How SQL:2011 implements it","paragraphs":["- A period is declared on a pair of date or timestamp columns (PERIOD FOR ...). Periods are closed-open.\n- A table with a user-named period is an application-time period table; one with the SYSTEM_TIME period and WITH SYSTEM VERSIONING is system-versioned; a table can be both.\n- Queries can ask for any past system state: FOR SYSTEM_TIME AS OF a time stamp, FROM ... TO (closed-open) or BETWEEN ... AND (closed-closed). Without these clauses, a query returns current rows only.\n- Updates and deletes can apply to part of a valid period (FOR PORTION OF).\n- A bitemporal query combines both axes: for example, the department an employee was in on one date, as recorded in the database on another.","Temporal tables entered the SQL standard in SQL:2011. Products implement them to different extents, so the syntax available varies."]},{"heading":"Changes and corrections","paragraphs":["The distinction that bitemporal data exists to preserve:","- **A change in the world** (a new chief investment officer, a fund extension) closes one valid period and opens another.\n- **A correction of the record** (the previous end date was wrong) adds a new version with the corrected valid period and closes the old version's transaction period.","A system with only valid time cannot tell these apart afterwards: a corrected period looks as if it had always been recorded that way. A system with only transaction time can show what changed in the record but not when the fact took effect."]},{"heading":"Why it matters in private markets","paragraphs":["- **Explaining past decisions.** What did the team know about a manager, its key people and its fund sizes on the date of the investment committee? That is an as-known question. See [point-in-time data](/glossary/point-in-time-data).\n- **Restated figures.** NAVs, track records and fund sizes are restated; both the original and the restated values remain retrievable.\n- **Role and relation histories.** Late-discovered departures and appointments can be back-dated in valid time without hiding when they were learned. See [temporal validity](/glossary/temporal-validity).\n- **Audit.** System-maintained history gives an audit trail that users cannot rewrite, one part of a value's [data provenance](/glossary/data-provenance)."]},{"heading":"Design and storage choices","paragraphs":["- **Deleting rows** destroys transaction history; a fact recorded in error is closed in transaction time, not deleted.\n- **Letting users edit transaction time** defeats the purpose.\n- **Far-future sentinels.** SQL system-versioned tables set the end of a current row to the highest value of the column type. For valid time, a sentinel end encodes \"no end observed\"; it should not be read as a statement that the fact is still true.\n- **Storage and query cost** grow with history; indexes and retention policies need to be planned, not added later."]},{"heading":"How Altss applies this (Altss methodology)","paragraphs":["Under Altss methodology, each version of a claim carries a valid-time interval and a transaction-time interval. Transaction time is append-only: when a claim changes, the new version is added and the old version's transaction interval is closed. A correction to a past value is recorded as a new version with the same valid time and a later transaction time; nothing is deleted or overwritten. A new version carries its own validation status while the earlier version keeps the status and date it held; each version's value keeps its derivation status, and each evidence item its evidence origin. Past states are retrieved in the current, as-was and as-known views. See the [Temporal Data & Freshness Methodology](/knowledge-center/frameworks/temporal-data-and-freshness-methodology)."]}],"classification_rules":[],"calculation_rules":[],"common_mistakes":["Storing one date per row and calling it temporal.","Treating a correction as if the world had changed, or a change as if the record had been wrong.","Using the source capture date as the transaction time.","Allowing users or batch jobs to rewrite system time stamps.","Deleting erroneous rows instead of closing them."],"edge_cases":["Retroactive facts: valid time starts before transaction time.","Proactive facts: a future appointment is recorded now with a future valid start.","Correcting only part of a valid period splits the row into pieces (FOR PORTION OF in SQL:2011).","A fact recorded in error and then withdrawn remains visible in as-known views for the period it was held."],"external_standard_mappings":[],"source_ids":["SRC-ACAD-KULKARNI-MICHELS-2012","SRC-ACAD-SNODGRASS-2000"],"citations":[{"source_id":"SRC-ACAD-SNODGRASS-2000","pinpoint":"Sec. 1.1 (kinds of time); ch. 2, sec. 2.3 (bitemporal tables)","supports":"Valid time and transaction time; a table supporting both is bitemporal","source":{"source_id":"SRC-ACAD-SNODGRASS-2000","title":"Developing Time-Oriented Database Applications in SQL","authors":"Richard T. Snodgrass","publisher":"Morgan Kaufmann","document_type":"paper","url":"https://www2.cs.arizona.edu/~rts/tdbbook.pdf","year":2000,"publication_date":"Morgan Kaufmann Series in Data Management Systems; ISBN 1-55860-436-7","jurisdiction":"intl","status":"Out of print; author-hosted PDF","last_verified":"2026-10-01"}},{"source_id":"SRC-ACAD-KULKARNI-MICHELS-2012","pinpoint":"Sections 2.1-2.4 (footnote 5 on the term \"bitemporal\")","supports":"SQL:2011 period definitions, system-versioned and application-time period tables, AS OF / FROM ... TO / BETWEEN queries, bitemporal queries, tamper-resistant history","source":{"source_id":"SRC-ACAD-KULKARNI-MICHELS-2012","title":"Temporal features in SQL:2011","authors":"Krishna Kulkarni; Jan-Eike Michels","publisher":"ACM SIGMOD Record","document_type":"paper","url":"https://doi.org/10.1145/2380776.2380786","doi":"10.1145/2380776.2380786","year":2012,"publication_date":"Vol. 41(3), pp. 34-43","jurisdiction":"intl","status":"Published","last_verified":"2026-10-01"}}],"faq":[{"q":"Is a system-versioned table bitemporal?","a":"No. A system-versioned table keeps transaction time only. It becomes bitemporal when it also has an application-time (valid-time) period."}],"seo":{},"first_published":null,"last_reviewed":"2026-10-01","last_modified":"2026-10-01","content_version":"2.0.0","url":"https://altss.com/glossary/bitemporal-data","json_url":"https://altss.com/reference/concepts/bitemporal-data.json","title":"Bitemporal Data","formulas":[],"sources":[{"source_id":"SRC-ACAD-KULKARNI-MICHELS-2012","title":"Temporal features in SQL:2011","authors":"Krishna Kulkarni; Jan-Eike Michels","publisher":"ACM SIGMOD Record","document_type":"paper","url":"https://doi.org/10.1145/2380776.2380786","doi":"10.1145/2380776.2380786","year":2012,"publication_date":"Vol. 41(3), pp. 34-43","jurisdiction":"intl","status":"Published","last_verified":"2026-10-01"},{"source_id":"SRC-ACAD-SNODGRASS-2000","title":"Developing Time-Oriented Database Applications in SQL","authors":"Richard T. Snodgrass","publisher":"Morgan Kaufmann","document_type":"paper","url":"https://www2.cs.arizona.edu/~rts/tdbbook.pdf","year":2000,"publication_date":"Morgan Kaufmann Series in Data Management Systems; ISBN 1-55860-436-7","jurisdiction":"intl","status":"Out of print; author-hosted PDF","last_verified":"2026-10-01"}]}