The time of the meeting is not arbitrary - it just corresponds to a date in a different calendar. Some calendars, e.g. the calendar used in Saudi Arabia, depend on observation of the new moon.
The time of the meeting is not arbitrary - it just corresponds to a date in a different calendar. Some calendars, e.g. the calendar used in Saudi Arabia, depend on observation of the new moon.
If you can't calculate a delta from $now, or "are $X and $Y the same moment in time" , I don't think "timestamps" are the tool. Seems beyond the scope of RFCs like this, at least to me.
Without guaranteed internet access, how would you set an alarm for "this day next year"? Timezones changing already cause problems there, but those were least correct at one point - not a "quantum timestamp" of sorts.
How many leap seconds will occur between now and when Europa Clipper intercepts Jupiter? That's actually important to know, e.g. for scheduling radio telescope time.
And let's not forget that some Pacific island nations have actually skipped entire days to just to another side of the date line.
The problem of "All future dates beyond the current year are currently unknown" is unsolvable in a very different way to "cultures and systems might change in the future".
(Though, wouldn't you be fine in your example? "X time after TS" wouldn't change, right? If you need atomic time anyways.)