We currently have many different systems that treat these values differently depending on the surrounding context, and the situation is becoming quite hard to reason about.

Here's a few I've faced on my way to implementing the primary cache:

• TimeInt::BEGINNING (which is i64::MIN / 2 ⚠️), if there's no timeline associated, is sometimes considered to refer to timeless data.
• TimeInt::BEGINNING (which is i64::MIN / 2 ⚠️), if there is a timeline associated, is just a very negative timestamp, I think..?
• TimeInt::MIN (which is i64::MIN), if there's no timeline associated, is sometimes considered to refer to timeless data.
• TimeInt::MIN (which is i64::MIN), if there is a timeline associated, is just a very negative timestamp, I think..? Might be interpreted as timeless in some contexts, it's hard to tell.
• Option<TimeInt> always unequivocally refers to timeless data.

In addition, a lot of our systems will work interchangeably with arbitrary i64 and TimeInt values which makes things even harder to reason about.
Also, special TimeInt values are sometimes interpreted differently when reading vs. writing data...

There are even more subtleties the deeper you dig, but you get the idea.

Ideally I would want either

1. timeless data to always be refered to using a time: Option<TimeInt> = None value, which is always unambiguous, irrelevant of the surrounding context; or
2. timeless data to always be refered to using a constant TimeInt value but A) it has to be the same everywhere and B) we must prevent code from instantiating that special TimeInt value in a timeful context.

2. is probably more realistic in practice and would also simplify a lot of the code e.g. in the cache.

In the meantime, I've tried to at least make everything use the same constant, but this resulted in a bunch of failed tests all over the place and I don't have time to look into this now.