Data Temporality

Assertive Time and Effective Time

suggested names for transaction time and valid time, where decision time is not used
why does transaction time need a period?
- if you have a history of transactions, the "current" state has no tx-end. old states have a timestamp of when they were superseded. Seems like you could impute an old state's tx-end tho, but I bet for querying, having the tx-end stored is nice.
- t.2024.07.12.14 in open-world assumption, or in cases of gaps where a fact gets (soft-)deleted and then re-created
- for clarity, perhaps "record-commissioned-at" and "record-decomissioned-at"

From Decision Time

for tri-temporal tables, the decision date will never be after the transaction date, while the valid date might still be arbitrary.

just made this up, it's like due date but doesn't have the "external constraint" sense
- created 2021-10-31
applies to intended activity (tasks), goals
could sometimes be represented as "ending instant/period of valid time"
Defining Done Is Hard
t.2024.07.12.14 probably just another application time

Triangle Distribution
- wrong: "The really nice thing about Triangle distributions is the Mean and the Mode are the same"

functionInDocument ::= 'CREATION_TIME' | 'EXPIRATION_TIME' | 'MODIFICATION_TIME' | 'PUBLICATION_TIME' | 'RELEASE_TIME'| 'RECEPTION_TIME' | 'NONE'

'[of MariaDB and Postgres], MariaDB supports temporal tables in the core product and sticks to the SQL:2011 standard most closely. I would recommend MariaDB for those interested in temporal tables in existing SQL databases.' 1
SirixDB and Xtdb
TerminusDB and Dolt
Strabon and Allegrograph

Children

Backlinks

Assertive Time and Effective Time