4 ms·

This kind data modelling happens all the time in quantitative finance, where you need to run historical scenarios (backtests). We just call that "point in time

This kind data modelling happens all the time in quantitative finance, where you need to run historical scenarios (backtests). 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

LAC-Tech 3y ago
so bi-temporal extends to n-temporal. interesting...
- cratermoon 3y ago
  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.
  - pphysch 3y ago
    Fascinating. While 2 is indeed a rare quantity/cardinality, "2-ness" is a ubiquitous quality of digital systems.
    - Terr_ 3y ago
      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".
  - lordwarnut 3y ago
    The irony being of course that there are two scenarios.
    - etherealG 3y ago
      Except for the exceptions. And off by one errors.
nerdponx 3y ago
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.
jgalt212 3y ago
Yes, I remember someone complaining about datomic not being able to handle multiple meanings for the "as of" column.
- refset 3y ago
  Probably this post: https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html 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).

LAC-Tech 3y ago

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

cratermoon 3y ago
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.
- pphysch 3y ago
  Fascinating. While 2 is indeed a rare quantity/cardinality, "2-ness" is a ubiquitous quality of digital systems.
  - Terr_ 3y ago
    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".
- lordwarnut 3y ago
  The irony being of course that there are two scenarios.
  - etherealG 3y ago
    Except for the exceptions. And off by one errors.

nerdponx 3y ago

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.

jgalt212 3y ago

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

refset 3y ago
Probably this post: https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html 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).