Temporal Validity

Valid time and transaction time

Valid time is about the world; transaction time is about the record. The two can differ arbitrarily: Kulkarni and Michels give the example of an insurance policy recorded well before it comes into effect. In private markets, a manager may announce in August that a new chief investment officer starts on 1 October. The fact is recorded in August and valid from 1 October. A database that keeps both axes is bitemporal.

Periods, not points

A valid period has a start and an end. SQL:2011 uses a closed-open convention: the period includes its start and excludes its end. Consecutive periods then meet without overlapping:

• Role held by person A: [1 March 2020, 1 July 2024)
• Role held by person B: [1 July 2024, end unknown)

On 1 July 2024 only B holds the role, and no day is counted twice. Two further rules keep periods honest:

• Unknown is not open-ended. "End unknown" means no end has been observed. It does not mean the fact is still true; whether it can be read as current is a question of data freshness.
• Precision is kept. A start known only to the year is recorded as a year, not padded to 1 January.

Where valid-time bounds come from

Bounds come from dates that sources state: an appointment's effective date, a transaction's completion date, a fund's final close, a registration's effective date, the as-of date of a filing. Filing, publication, capture and recorded dates are not valid-time bounds (see evidence dates). When the only evidence is that a source changed between two captures, change detection brackets the change (after the earlier capture, on or before the later one); that bracket is not the effective date and is replaced if a source later states one.

Querying by valid time

Valid time makes "as at" questions answerable: which plans had a target allocation to private credit on 31 December 2024; who sat on an investment committee when a commitment was approved; which funds were in their investment period in a given year. A list "as at" a date must include entities and relations valid on that date, including those that later ended, or the result suffers from survivorship bias. SQL:2011 also lets an update or delete statement apply to part of a period (the FOR PORTION OF clause), which splits the period instead of overwriting it.

Private-markets facts that have validity periods

• A person's role at an organisation; successive roles form the person's role history.
• A relation between entities: general partner of, advised by, subsidiary of (relationship graph).
• A fund's lifecycle phases: investment period, extensions, wind-down.
• An adviser's registration status and an entity's legal name.
• An allocator's investment mandate and target allocations.
• An ownership interest or a beneficial ownership position.

Static facts, such as a fund's vintage year or the date of a past event, are dated but do not have a validity period that can end.

How Altss applies this (Altss methodology)

Under Altss methodology, valid-time bounds are taken only from dates the sources state; a capture, filing, publication or recorded date is never copied into a valid-time bound. Valid-time bounds are not evidence fields: a bound read from a date a source states has derivation status OBSERVED and carries the evidence origin of that source, and the claim's validation status is recorded separately with its own date. Intervals are closed at the start and open at the end, and an unknown bound is recorded as unknown, not left empty and not treated as open-ended. A claim with a future effective date is labelled scheduled until that date passes. Whether a claim with no observed end may be read as current is decided by its freshness, not by the open end. See the Temporal Data & Freshness Methodology.

Not the same as

• Bitemporal Data: Temporal validity is one time axis (the world). Bitemporal data adds the second (when the record held each version).
• Evidence Dates: Effective dates bound valid time; evidence dates also include filing, capture, recorded and verification dates, which are not valid time.
• Point-in-Time Data: Point-in-time data reproduces what was known at a past date; that needs transaction time as well as valid time.

Common mistakes

• Overwriting a value when the fact changes, instead of closing the old period and opening a new one.
• Using the date a fact was recorded or published as its valid-from date.
• Reading a missing end date as proof that the fact is still true.
• Allowing overlapping periods for an attribute that can only have one value at a time.
• Using inclusive end dates, so the changeover day is counted in both periods.
• Padding a year-only start or end to a full date.

Edge cases

• Retroactive facts: a filing in 2026 reveals a change effective in 2025. Valid time starts in 2025; the record shows it was learned in 2026.
• Future-dated facts are recorded with their effective date and treated as scheduled until it passes.
• Some attributes can hold several values at once (a person on two boards); periods may then overlap legitimately.
• A correction to a period end is a change in what is known, not a change in the world; it needs transaction time to be recorded without losing the earlier belief.

Questions

Sources

1. Temporal features in SQL:2011. Krishna Kulkarni; Jan-Eike Michels, ACM SIGMOD Record, Vol. 41(3), pp. 34-43. Status: Published (checked 2026-10-01). Sections 2.1 (closed-open periods; valid vs transaction time) and 2.2 (application-time period tables, FOR PORTION OF) — supports: Definitions of valid and transaction time; closed-open period model; partial-period updates
2. Developing Time-Oriented Database Applications in SQL. Richard T. Snodgrass, Morgan Kaufmann, Morgan Kaufmann Series in Data Management Systems; ISBN 1-55860-436-7. Status: Out of print; author-hosted PDF (checked 2026-10-01). Sec. 1.1 (kinds of time); ch. 2, secs. 2.1-2.3 (valid-time, transaction-time and bitemporal tables) — supports: Valid time is when a fact was true in the modeled reality; transaction time is when it was stored in the database

• Bitemporal Data
• Point-in-Time Data
• Evidence Dates
• Data Freshness
• Relationship Graph
• Investment Mandate

• Entity Resolution
• Triangulation (Source Triangulation)