so bi-temporal extends to n-temporal. interesting...

There's an old saying "two is an impossible number". In programming, we either deal with one of a thing, or a collection of things. The cases where there are exactly two things are uncommon (cue HN coming up with a bunch of exceptions). In the case of points in time, even bi-temporal leaves out a third, implicit point: now.

Fascinating. While 2 is indeed a rare quantity/cardinality, "2-ness" is a ubiquitous quality of digital systems.

By human choice, though. We could be using N different thresholds of electrical charge or current, but instead we define ranges as "0-enough" and "1-enough".

The irony being of course that there are two scenarios.

Except for the exceptions. And off by one errors.

This is similar to what I deal with at work, where we have a large number of devices (dare I say "IoT") that all send data to a cloud system. There's the time that each record was recorded, the time it was sent, the time it was actually picked up from the queue for processing, and so on.

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.

Yes, I remember someone complaining about datomic not being able to handle multiple meanings for the "as of" column.

Probably this post: https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this...

> 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).