> Past events should just be stored as instants, not as a local time plus location or time zone.

Appointments become past events. Sounds like an operational nightmare to convert all of them right as they become past events.

And you absolutely want the time zone (and offset) if you want to show past event as a local time for where that event was held. You don't need the location because you know what time zone rules governed that location at that point in time in the past. It won't change.

Please consider that I phrased my comment in engineering terms. I already acknowledged that you want a physical location for the best results in all cases, as you have pointed out in this thread. But I also was careful to contextualize it in engineering terms: storing that information comes with extra engineering costs over just storing an RFC 9557 string. Sometimes those costs are worth it, but certainly not for every use case.

> Further, I believe the historical data is meant to be handled by the named time zone, so Russia moving Dnipro to MSK would create a new time zone, call it Europe/Dnipro, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) Europe/Dnipro, and the historical changes of Dnipro would be handled by tzdb.

I can believe that this is what would happen.

> Appointments become past events. Sounds like an operational nightmare to convert all of them right as they become past events.

That is fair. In some models there's a natural separation between a scheduled-at time and a happened-at time (e.g., in one I worked on scheduled_events was a separate table from past_events), but I accept that's certainly not all, or even most. I shouldn't have made such a blanket statement. I do believe the statement is good advice in cases where your data does not mix both future and past times.

> Sometimes those costs are worth it, but certainly not for every use case.

This is also fair. My experience with time zones has been the more correct I can make my time models, the better I sleep at night, but of course you're right engineering involves tradeoffs. I think it's important to at least know the most correct way so that you are making educated decisions in your tradeoffs.

Also, FWIW I'm not the person you originally replied to, although the Ukraine example was mine.