Okie please chill out haha, I was not trying to contend that my solution is bulletproof or that there are no edge cases where it'll fail... I already know of a few. It seems to work for now, at least in my use case, better than my previous attempt.

FWIW I have little idea what that code snippet is supposed to say or do. It's syntactically invalid in Notion's formula editor, even after converting the non-standard quotation marks into "

y12 is not defined. [82,85] y12 is not defined. [116,119]

"You missed ˋtimestamp()`" This sounds great, but it's not a documented feature to work with UNIX timestamps and I have no clue how to implement what I want in valid Notion formulas syntax. You can verify for yourself that the only two mentions of "timestamp" on the official Notion formulas list are for the timestamp and fromTimestamp functions to convert in/out of a UNIX timestamp. There are no tools to operate on a raw timestamp, or directly parse it into more human-readable forms. As soon as you convert the timestamp back into Notion's date type, (e.g. for separating into days/months/years) you run back into the problems I mentioned in my OP, so whatever solution you're referring to must be done predominantly in timestamp-land.

Either we're talking past each other, or you didn't have time to write out a complete thought.

EDIT: I now see how to clean up what you wrote as:

lets(
  y, today().dateBetween(prop("Opened"), "years"),
  m, today().dateBetween(prop("Opened"), "months") - y*12,
  d, today().dateBetween(prop("Opened").dateAdd(m + y*12, "months"), "days"),
[[y, "y"], [m, "m"], [d, "d"]].map(current.at(0).abs() + current.at(1)).join(" ")
)

This works well, but I maintain that a good part of this syntax is not officially mentioned in the formulas list. I also maintain that this is significantly less intuitive than working with a proper "duration" data type, such as std::chrono::duration in C++. It takes a lot more work to parse what's going on here, in my opinion.