Valid time describes when information applies in the world being modeled. Record time describes when that information was represented in a system’s records. These timelines often overlap, but they answer different questions.
A regulation might take effect on January 1 and enter a database on January 5. January 1 is its effective date—a valid-time boundary. January 5 is its recording date—a record-time boundary. Neither date replaces the other.
Preserving this distinction helps systems retrieve historically appropriate information, explain earlier decisions, and incorporate corrections without erasing what the records previously said.
In this article
The two timelines
Valid time: when the information applies
Valid time locates a fact, condition, or relationship within the period it describes. An employee belongs to a department during certain dates. A price applies during a promotion. A regulation governs activity from its effective date until it is replaced or withdrawn.
Valid time may be represented as a date, an instant, or an interval. A department assignment, for example, might apply from March 1 until July 1.
The word valid does not certify that the information is correct. It identifies when the recorded assertion is intended to apply. An incorrect assertion can still have a valid-time interval and later require correction.
Record time: when the system represented it
Record time locates information within the history of a particular system’s records. It describes when an assertion entered that recorded history and, where versions are retained, when it was superseded.
This is often called transaction time in temporal database terminology. Some platforms use terms such as system time. The exact behavior depends on the implementation, so a system’s documentation should define what its timestamps actually measure.
Record time is not necessarily when a person first learned something, when a source published it, or when another system received it. A database entry establishes something about that database’s history—not everything an organization knew.
Why the timelines diverge
Information may arrive late, be entered in advance, or be corrected after the period it describes:
- Late entry: a January 1 policy change is recorded on January 5.
- Advance entry: a scheduled July 1 price change is recorded in June.
- Retroactive correction: a department assignment recorded in March is corrected in April, with the correction applying to March.
These are ordinary information-management situations. A model that keeps only one timeline may struggle to represent them without losing useful history.
Publication, modification, effective, and record dates are different
A document or database record can carry several dates, each describing a different event.
| Date or timestamp | Question it usually answers |
|---|---|
| Publication date | When was this document or version made available? |
| Modification date | When was this document or record changed? |
| Effective date | When does the stated rule or condition begin to apply? |
| Ingestion timestamp | When did this receiving system ingest the material? |
| Record-time boundary | When did this assertion become, or stop being, part of the system’s recorded state? |
These dates can coincide, but that coincidence should not be assumed. A document published in December may describe a rule effective in January. A February edit may fix punctuation without changing the rule’s applicability.
A field named updated_at is therefore not enough to establish temporal meaning. Its meaning depends on what triggers the update and what history, if any, is retained.
A bitemporal example: retaining a correction without erasing history
Bitemporal data modeling preserves both valid time and record time. It can represent when an assertion applies and when the system held that version of the assertion.
Consider a fictional eligibility rule:
- The rule takes effect on January 1.
- On January 5, a database records the eligibility limit as $50,000.
- On January 12, a reviewer discovers a transcription error. The source rule specified $45,000 from January 1.
The January 12 entry corrects the database’s description of the rule. It does not introduce a new eligibility limit beginning January 12.
| Recorded limit | Valid from | Valid until | Recorded from | Recorded until |
|---|---|---|---|---|
| $50,000 | January 1 | No end recorded | January 5 | January 12 |
| $45,000 | January 1 | No end recorded | January 12 | No end recorded |
This illustration uses inclusive starts and exclusive ends: the first recorded version applies to record-time queries from January 5 up to, but not including, the January 12 correction boundary. A production system may need exact timestamps rather than dates.
The two rows are not competing current answers. They describe different versions of the recorded history. Based on the corrected record, the limit applying on January 3 was $45,000. But on January 8, this database represented that limit as $50,000.
Simply overwriting $50,000 with $45,000 would preserve the corrected value while losing evidence of the earlier recorded value.
Four historical questions that need different answers
The phrase “What was the limit on January 3?” is incomplete when both timelines matter. It could mean several things.
1. What applied on January 3, according to our current records?
This asks for a historical valid date using the current recorded understanding. After the correction, the answer is $45,000.
2. What did our records say on January 8 about January 3?
This fixes both timelines: valid time is January 3, and record time is January 8. The answer is $50,000.
3. When did this database record the correction?
This asks about the record timeline. In the example, the correction entered the database on January 12. That does not, by itself, establish when the source issued the correct information or when a reviewer first noticed the error.
4. What would the database have returned on January 4?
For this rule, the modeled history contains no entry yet: the first recording occurred on January 5. That absence is not evidence that no rule applied. It means this database had not recorded it within the history being queried.
Even when both timelines are preserved, reconstructing an entire historical search result may require more than the underlying facts. Search indexes, permissions, ranking logic, query parameters, and application versions may also have changed.
Why valid time and record time matter for retrieval
A passage can be relevant to a topic and still be inappropriate for the date in the question. Retrieving the newest document is not always the same as retrieving the right historical evidence.
A useful temporal retrieval process distinguishes:
- The period being asked about: when the condition or rule applied.
- The evidence cutoff: which recorded information may be used to answer.
- The source and scope: whose records, which jurisdiction, or which version the answer concerns.
For example, “Explain the decision made on January 8 using the records available then” differs from “Reassess the January 8 decision using the corrected records available now.” Both are reasonable tasks. Mixing them can produce an explanation that quietly relies on information recorded only later.
In a retrieval-augmented workflow, temporal filtering may occur before or alongside ranking. The applicable dates and record history should also remain attached to the retrieved evidence during context assembly, rather than disappearing when a passage is extracted.
A grounded answer can make the distinction explicit: “According to the corrected record available now, the limit was $45,000. The database still showed $50,000 on January 8.” This supports grounding AI-assisted answers without presenting recorded assertions as unquestionable truth.
Practical decisions when modeling both timelines
Bitemporal modeling is more than adding two timestamp columns. The system needs rules for intervals, corrections, queries, and retained history.
Define the assertion and its scope
Identify what each record describes. A price needs a product, currency, and perhaps a market. A regulation may need a jurisdiction and provision. Temporal precision cannot repair an assertion whose subject or scope is unclear.
Document interval boundaries
State whether end boundaries are inclusive or exclusive. Half-open intervals—start included, end excluded—can make adjacent periods easier to manage, but they are a modeling choice, not a universal requirement.
Also distinguish “no end is currently recorded” from “this will remain true forever.” An open-ended record usually expresses the system’s present information, not certainty about the future.
Choose appropriate time precision
A policy might take effect on a local calendar date, while a database transaction occurs at a precise instant. Preserve those different meanings. Where timestamps are used, define time zones and how simultaneous or closely spaced changes are ordered.
Separate a correction from a real-world change
A corrected transcription may replace an earlier assertion about the same valid period. A genuine policy change may start a new valid period. Both can create new recorded versions, but their valid-time effects differ.
Preserve provenance as well as dates
Dates do not explain why a value should be trusted. Retain appropriate source references, correction reasons, and review information. Document provenance complements temporal history by showing where assertions came from.
Test historical questions directly
Useful test cases include a late-arriving record, a future-effective change, a retroactive correction, and a query from before the first entry. Where overlapping valid periods are not allowed, test those constraints too.
Verify the database’s actual capabilities. A system-versioned table may preserve record history without modeling valid time. A last-modified field alone generally cannot reconstruct previous states.
When both timelines are worth keeping
Bitemporal modeling is especially useful when late information, retroactive corrections, historical decisions, or audit questions are routine. Eligibility systems, personnel records, pricing histories, and regulatory reference systems can all encounter these conditions.
It is not necessary for every application. A current-information page may need only a clear effective date and a revision history. Other systems may meet their requirements with retained snapshots or a carefully designed audit log.
The decision depends on the questions the system must answer. If readers or reviewers need both “What applied then?” and “What did these records say then?”, preserving both timelines becomes substantially more useful.
The central distinction is simple: when information applies is not the same as when it was recorded. Naming those meanings clearly helps prevent current knowledge from silently replacing historical evidence—and helps people understand both the corrected account and the record that preceded it.