[akio]

The events in question happen at a physical location at a local time, and so are stored as a local time plus longitude and latitude.

If they were stored as instants, and then if a location moved time zones or stopped using DST in the summer, the event’s stored time relative to the expected local time would incorrectly shift.

[omnicognate]

That's logically fine, although it strikes me as likely overkill since your system has to be able to look up a convention by lat/long in order to get an instant in time, which is not trivial to do and for most use cases would be a more frequent source of errors than changing timezone definitions. I don't know the details of your use case though, and this could well be the appropriate representation. The main thing is that enough information is present to identify an instant in time. Your scheme isn't the nominal-datetime-only representation that I pointed out is frequently used but rarely correct.

[akio]

We agree that you generally want some information that lets you resolve your event to an IANA time zone for calculations :)