Transaction time

Transaction time tracks when a database recorded an assertion as present, and when a later operation superseded that recorded state. It is tied to the system's history, not to the period when the assertion applied in the world. A document can describe an event from January while first entering the record in April. That entry cannot honestly become part of the system's January knowledge state merely because its subject matter is old.

Reliable use requires preserving previous states and assigning timestamps according to a defined clock and commit boundary. Import time, ingestion time, and review time may all differ; the chosen transaction timestamp should have a documented meaning. Corrections normally create a new recorded state rather than rewriting the old one. Replication and backfills need special treatment because the time a source was originally created is not the time a receiving system recorded it.

Transaction time supports an answer to what a decision maker could have found in the record at a specified point. It is particularly useful in audits following late evidence or a disputed correction. It does not show when a proposition was true in the outside world, nor whether a decision maker actually saw it. Those questions require valid time, access evidence, and the underlying sources alongside the recorded history.

Clock reliability matters. If transaction time comes from a server clock, clock skew between servers can place two writes in the wrong order; designs that need strict ordering use a single sequencer or logical clocks. Batch loads need care: a nightly load that stamps every row with the load time hides the order in which the underlying changes happened. Late-arriving data should keep its arrival time as transaction time and carry its real time as valid time, so that the delay is visible.

Deletion and privacy complicate the picture. Retaining all history conflicts with obligations to erase personal data; a design must decide which history is kept, for how long, under the retention schedule, and how erasure is performed without breaking the integrity of the rest of the log. Such decisions should be taken in advance and recorded, and not discovered during a request. The article on valid time versus transaction time discusses these clocks together with observation and publication time.

Ask whether a change to a stored value creates a new version or edits in place. Ask whether ordinary users can alter history. Ask how late-arriving data are stamped. Ask how erasure requests are reconciled with history. Reproduce a figure from an earlier report by querying as of the report date, and compare it to what was published.