Yeah, it seems like there's no general solution to this. If I put in '10AM in Chile' for grabbing coffee with a friend, I probably want it to stay in wall time no matter what happens to the offset.

If I'm making a note of a solar eclipse, I need it to stick with physical time, and if the offset changes the reported time changes.

If I'm scheduling a conference call to Australia, then when the offset changes, one of us is going to have to reschedule, and my calendar can't know which. (We might both have to reschedule, if neither of us can move it by a single hour.)

It might be able to say "you scheduled this at 10AM, but the DST rules changed, and that physical time is now 11AM wall time, what to do?" My Australian colleague isn't going to get that warning, unless her calendar knows that she's talking to someone in Chile, but as long as one of us knows about the problem, we should be okay. But I'm not sure I trust this to cover all bases.

Let's say the meeting is supposed to take place at 15:00 "wall time" in Sydney on March 30th. Someone changes the DST rules. The meeting still takes place at the specified time. Remember we specify the time at Australia. So far so good.

Usually the time from a new update is released at least a week before the change takes place. So your software might alert you about the time on the same day or the day before of the meeting. Or even half an hour before. Do the calculations at that time of the alert with the newest timezone data. And if the software is up to date with timezone database changes, users in other time zones will be alerted about the correct time. The calculation will be made before the meeting from 15:00 Sydney to whatever other time zone someone might be in.

Why would the time for the Australian be incorrect? If the meeting organizer is in Chile, then the meeting time would be ruled by Chile's local clock. If the rule change affects the difference between Australia and Chile, then simply loading the updated rules on both sides should readjust things automatically - if the time was stored as Chile local, not UTC.

The fact that the meeting organizer in Chile does not imply that the key constraint for the meeting time was in Chile, rather than in the schedule of the Australian attendees.

(Of course, its actually possible that there were essential constraints on both sides, in which case, the problem is more difficult, or that the key constraint was that the call needed to immediately precede or follow an event in a timezone different from Australia or Chile.)

Really, determining the key intent here is hard, and there is no one rule that makes it painless in all cases. There are lots of different possible intents with timing, and there is no single general rule that handles all possible changes in local time rules between the time an event is scheduled and the time it occurs.

If I enter "10:00 in Chile" in a calendar app I expect it to stay "10:00 in Chile". And not magically change to "11:00 in Chile". That is what the example was.