> The conversion to UTC will lose the original local time so you cannot retrieve it once time zone data changes, unless you perform reconversions every time you detect such a change in tzdata
I don't agree/disagree with your point, and neither I do agree/disagree with GP on the topic, but why couldn't I retrieve the original time? If, for an event, I save UTC + event TimeZone, I can always get back to the original time (actually, it doesn't even matter whether the timestamp is UTC; it's enough for it to have an explicit offset, i.e. to be the representation for an instant). Why should I change the timezone on a saved record? What usually changes is the user's timezone, not the records'.
> Thus it is important to distinguish between instants and wall clock time
Yes.
> For more information Jon Skeet has written about this multiple times.
I have read many things on datetime; would you care to share a couple of relevant links?
Offset timezones (e.g. UTC+2) don't change, what changes are local timezones (e.g. Europe/Rome).
For example here Turkey decided to change daylight savings time: https://github.com/JodaOrg/joda-time/issues/403 (if you have a look at the tzdata database you will find more, this one I remember because Turkey went back and forth about this).
If your timezone database changes you cannot retrieve the original wall clock time, unless you have a temporal timezone database and remember the date of conversion to UTC.
And if you used offsets instead of local timezones to begin with, you cannot even infer which offsets to change unless you have location data saved as well.
> For me, the key difference between the options is that in option 3, we store and never change what the conference organizer entered. The organizer told us that the event would start at the given address in Amsterdam, at 9am on July 10th 2022. That’s what we stored, and that information never needs to change (unless the organizer wants to change it, of course). The UTC value is derived from that “golden” information, but can be re-derived if the context changes – such as when time zone rules change
I'm sorry for the late response; yes, you are right that for future events the "right way to do it" is saving the place + local time. I think we were speaking of slightly different things.
I don't agree/disagree with your point, and neither I do agree/disagree with GP on the topic, but why couldn't I retrieve the original time? If, for an event, I save UTC + event TimeZone, I can always get back to the original time (actually, it doesn't even matter whether the timestamp is UTC; it's enough for it to have an explicit offset, i.e. to be the representation for an instant). Why should I change the timezone on a saved record? What usually changes is the user's timezone, not the records'.
> Thus it is important to distinguish between instants and wall clock time
Yes.
> For more information Jon Skeet has written about this multiple times.
I have read many things on datetime; would you care to share a couple of relevant links?