We just call that "point in time" (PiT) data. There can be multiple dimensions of timestamping, but you often end up with:
- published date: when was this information publicly available
- received date: when was this information actually received in our systems
- effective date: when does this information starts applying
It also arises in ETL systems like Apache Airflow, where the "logical date" of a task run might or might not correspond to the date it was actually run.
The common element here is that the time relationships are not monotonic, and you occasionally have to make business decisions around that non-monotonicity.
> If you're new to Datomic, you probably have the same misconceptions as I did regarding the use of Datomic's historical features.
> bad news: you've probably over-estimated the usefulness of these features for implementing your own specific time travel. Unless you really know what you're doing, I recommend you don't use db.asOf(), db.history(), and :db/txInstant in your business logic code.
> good news: you've probably under-estimated the usefulness of these features for managing your entire system as a programmer.
>I believe the key to getting past this confusion is the distinction between event time (when things happened) and recording time (when your system learns they happened).