This is an important and surprisingly tough issue. The truth is that there is no completely satisfying stardard for persisting time. For example, the SQL standard and the ISO format (ISO 8601) are clearly not enough.
From the conceptual point of view, one usually deals with two types of time-date data, and it's convenient to distinguish them (the above standards do not) : "physical time" and "civil time".
A "physical" instant of time is a point in the continuous universal timeline that physics deal with (ignoring relativity, of course). This concept can be adequately coded-persisted in UTC, for example (if you can ignore leap seconds).
A "civil" time is a datetime specification that follows civil norms: a point of time here is fully specified by a set of datetime fields (Y,M,D,H,MM,S,FS) plus a TZ (timezone specification) (also a "calendar", actually; but lets assume we restrict the discussion to Gregorian calendar). A timezone and a calendar jointly allow (in principle) to map from one representation to another. But civil and physical time instants are fundamentally different types of magnitudes, and they should be kept conceptually separated and treated differently (an analogy: arrays of bytes and character strings).
The issue is confusing because we speak of these types events interchangeably, and because the civil times are subject to political changes. The problem (and the need to distinguish these concepts) becomes more evident for events in the future. Example (taken from my discussion here
John records in his calendar a reminder for some event at datetime
2019-Jul-27, 10:30:00, TZ=
Chile/Santiago, (which has offset GMT+4, hence it corresponds to UTC
2019-Jul-27 14:30:00). But some day in the future, the country decides to change the TZ offset to GMT+5.
Now, when the day comes... should that reminder trigger at
2019-Jul-27 10:30:00 Chile/Santiago =
UTC time 2019-Jul-27 15:30:00 ?
2019-Jul-27 9:30:00 Chile/Santiago =
UTC time 2019-Jul-27 14:30:00 ?
There is no correct answer, unless one knows what John conceptually meant when he told the calendar "Please ring me at
2019-Jul-27, 10:30:00 TZ=Chile/Santiago"
Did he mean a "civil date-time" ("when the clocks in my city tell 10:30")? In that case, A) is the correct answer.
Or did he mean a "physical instant of time", a point in the continuus line of time of our universe, say, "when the next solar eclipse happens". In that case, answer B) is the correct one.
A few Date/Time APIs get this distinction right: among them, Jodatime, which is the foundation of the next (third!) Java DateTime API (JSR 310).