I don't think future vs past is a good distinction. There is really not a succinct rule of thumb (the common one, "just use UTC", can mean multiple things and c

I don't think future vs past is a good distinction. There is really not a succinct rule of thumb (the common one, "just use UTC", can mean multiple things and can mislead juniors), which is a symptom of the conceptual complexity of distinguishing time as a physical measure vs time as a cultural construct. This is compounded severely by the insistence of many languages, libraries, and platforms of calling absolute times "Dates" and reinforcing that lie by silently picking arbitrary tz offsets to add to your absolute times at API edges - perhaps the single most destructive cutesy convenience in the history of software. The only real rule of thumb is: If the clock time, calendar date, or tz offset matter in your use case, store them. Otherwise, use absolute time. Learn how your platform stores time and then you will see where your tools are doing the conversion for you, and STOP them from doing it.