[zamadatix]

Times in the future are always unreliable, even using the "normal" system there aren't any guarantees that specific time will even exist or if it does you still need to think about "is it an absolute event or a relative event and does it need to have the time updated as a result" just the other way around.

[mort96]

Sure. But the important difference is: I can express the time "2nd of March 2056, 15:00 UTC", we can talk about that future time, and we can tell whether we're before or after that time. But I can't express the same time in unix time, because I don't know how many leap seconds will be between now and March 2056.

[zamadatix]

Sure you can, just allow for sticking the things you want to track against at the end like you did after saying "2nd of March 2056, 15:00". If that's leap seconds then there is no reason you can't say "<future timestamp> with leap second changes" just the same as you did there with a datetime. What you can do with a timestamp is a superset of what you can do with a datetime since you start with fewer limitations but lose none of the ability to apply or mark needed transformations to that base:

Guarantees about <future date> UTC:

- Can calculate duration from past to <future date>: No (need future leap second table)

- Can calculate duration from now to <future date>: No (need future leap second table)

- Can calculate duration from future to <future date>: No (need future leap second table)

- Can compare <future date> to <future date>: No (UTC is not monotonic)

- Can know if <future date> is unique: No (UTC is not monotonic)

- Can determine <future date> has passed: After passing

- Can determine <future date> will occur: After passing (time skip adjustments and whole date skips allowed in calendar)

Guarantees about <future date> timestamp:

- Can calculate duration from past to <future date>: Yes

- Can calculate duration from now to <future date>: Yes

- Can calculate duration from future to <future date>: Yes

- Can compare <future date> to <future date>: Yes

- Can know if <future date> is unique: Yes

- Can determine <future date> has passed: Yes

- Can determine <future date> will occur: Yes

Once you add "accounting for leap seconds" to the timestamp all but "Can determine <future date> will occur" will match up. UTC didn't gain anything over timestamps in that case the difference between the two just shrunk.

While you may be able to say "I know what the UTC encoding will look like ahead of time if I specify it in UTC encoding" that doesn't actually give you any more information about the time as you can't do anything functional with that knowledge until the time passes at which point, provided the same info you had to accurately track the UTC time, you have enough information to do the same with a timestamp.