Yes, whether the location/context of the event is relative to you or some other location. I.e. Someone outside Chile creates an event to track the start of a football game in Chile before the change mentioned in the article.
What you really want is an absolute time, and a localized timezone that applies to the event (which may not be your own).
Ah, I wasn't clear enough ... I was thinking in that case the canonical calender event would be encoded in time in Chile, even if the local calender was in Germany or whatever. Looking back that could have been written much better so I've added a parenthetical.
Surely the right approach to handling scheduling like this is (sticking with the calender example) a) initiating calender event is canonical (but may or may not be in the calenders local timezone) , but b) metadata about when the schedule was made and last updated is stored, and c) every future computation takes this metadata and looks up canonical (i.e. IANA) timezone/change information every time it touches the event, and d) a warning is given to any user, at any time their localization has a change in rules that might affect their apparent wall time, plus e) any changes in the localization of the initiating/owning calender trigger a warning for everyone.
Am I missing something? [edit: besides the way to format this list...]
(added - I should have been more clear that the server is only responsible for keeping track of the canonical event and updating clients if and when that changes. The clients will always be responsible for resolving locally apparent changes)