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.
