It depends. It could be a meeting in a particular city at 4pm local time. A "+02:00" or "-05:00" specifier is insufficient because the government of the particular city/country might change the time zone rules between now and when the event is to occur. So you really need to store "2018-08-01 16:00:00 America/Argentina/Buenos Aires" for example, because maybe after 2018-06-01 they decided to go for "-05:30".

Indeed. There's a concept of relative physical time

a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter.

and relative calendar time

b) "I'll meet you 15:00 next monday".

Both of which are valid.

What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all?

I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though.

[1] Calender-type application is actually pretty niche IME. Opinion may vary.

The meaning of the date will not change compared to the UTC absolute coordinates, but usually users care only about their local time. If you set an alarm to wake you up at 8:00, you expect it to ring at 8am your time every day. What if in future user's local time zone gets changed - say if daylight savings are abandoned, as many countries consider doing - The user might not be in +2 offset anymore and when you convert it to the local time the alarm will ring at 7am or 9am instead of 8:00. It's definitely not what user would expect.

what the user expect is of course completely different if there’s not one but several users, or several referentials.

Then adapting for local time will screw any schedule not pegged to local time (even for stuff as trivial as following an international event)

Time is hard.

The meaning of “2018-05-26T13:45:21+02:00” may not change, but if 2018-05-26 rolls around and the restaurant where you have a lunch reservation at 13:45 local time is no longer in the +02:00 time zone, it’s not the same time that your reservation is scheduled for anymore.

But users want wall clock time. That you stored 2018-05-26T13:45:21+02:00 is irrelevant. The user wants that time to change if the original timezone's definition changes.

So you really need to store {datetime, timezone_name}.

It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.

>Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change,

It will respective to the local time though if a state decides to stop honoring DST or changes TZ.

I once ran across a book of changes over time to local time zones, I believe for historical research. It was the size of a phone book.

Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages.

Covers probably well over 100K locations each with its own history of timekeeping.