The users will rightfully expect their time to stay 14:00 Santiago time if they enter 14:00 Santiago time.
Intervals should be stored in UTC. If you're supposed to drop the control rods in a reactor in 24 hours you store the time it's supposed to happen in UTC. DST transitions and rule changes would mess this up if stored in local time.
Timestamps for logs and files should also always be UTC.
If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules.
Always store in UTC. Your argument makes no sense.
For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones.
Storing in local and then converting from one timezone to another timezone on demand has far more edge cases and gotchas. Plus it too isn't immune from rule changes, if you store in local time (e.g. 10 am) but DST rules changes, from an outside observer's perspective (someone in any other timezone) the meeting's time has now changed.
So even just using that edge case you're talking about exchange one downside (local time changes) to another downside (remote time changes).
Saving as UTC doesn't really solve the issue (although it seems like it does).
The issue that the previous posters (Khao, laut) didn't make explicit is that we have 2 concepts of datetimes:
1) scientific datetime (which UTC is unambiguous, except for obscure things such as leap seconds)
2) socially-constructed datetime (which "local" time + TZ resolves most (but not all) of the ambiguities)
Scientific(UTC) datetime works great for past events like server logs, and some types of future events such as celestial events. For example, the upcoming solar eclipse in August 21 2017. Regardless of what future DST rules are decreed by the government, the moon is going to move in front of the sun at a 16:48:33 UTC time.
Socially-constructed future datetime such as appointments don't work the same way. For example, we presume that a Super Bowl on the east coast in the year 2025 will have a kick off of 6:30pm but we can't encode that as UTC unambigously because we don't know today what DST rules will be in effect 10 years from now. In 2016, we don't know whether to encode it as 22:30UTC or 23:30UTC.
That said, if the planning horizon is short (such as sending out alerts for an upcoming conference call to participants spanning timezones), one can encode it as UTC internally and then decode it to local wall-clock time. It may be simpler that way with less bugs.
