Если бы нам повезло жить в мире, где все изменения и коммуникации происходят мгновенно, то жизнь в IT упростилась бы, но в фактически, иногда, происходят ошибки, уточнения, исправления которые необходимо фиксировать в реестрах и базах данных. Проблема в том, что не всегда возможно переписывать историю заключенную в виде строк в БД, к тому же это может быть небезопасно с точки зрения приложения. Иногда это практически невозможно, например, в случае с блокчейном. Есть замечательная статья об этом, в которой нас подводят к этой проблеме через пример: некая Салли получает повышение зарплаты и письмо от HR приходит с опозданием, платежная ведомость уже была сформирована на «старую» сумму, когда фактически должна была быть уже на «новую». Проблема усугубляется тем, что в письме содержалась ошибка и через несколько дней приходит новое, уточняющее письмо с уточненной суммой. В итоге получается что нам нужно дважды переписывать историю, причем мы просто потеряем эту информацию спустя время, ведь об инциденте не останется следа. Решение сводится к тому, чтобы сохранять информацию о фактическом времени наступления события и о времени записи.

Оказывается что это не просто сухая теория, существует компания marklogic которая создала коммерческую документоориентированную СУБД и продвигает эту концепцию, вот их описание проблемы https://www.marklogic.com/blog/bitemporal/, а вот более краткая презентация. Есть и opensource вариант — https://opencrux.com/main/index.html, вообще после описания идеи temporal databases в стандарте SQL:2011 многие СУБД начали реализовывать эту фичу у себя.

В итоге: эта идея заключается в сохранении информации не только о фактах (как в традиционных БД), но и о наших знаниях об этих фактах в определенный момент времени.