I disagree. Storing as UTC is the only sane way. It will never get corrupted. Calculating the timezone difference for the user is not that hard and won't result in a database full of mistakes you have to scramble to fix.
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.
If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
YOU just rescheduled the event.
Works the same with dates and not just times. If you store each of those events individually and the politicians move the DST switch date (or an error was corrected in the TZ database) then some of your event times will now be an hour off.
UTC is still the correct way to store it if you want it to be timezone-aware.
If every event a specific application needs to be at local time regardless of what the timezone is, stop storing any reference to a timezone.
UTC is the correct was to store timestamps (things that happened) and intervals (things that need to happen x seconds/minutes/hours from now).
For future events at a specific geographical location you need to store it as local time + timezone. Many databases have a time+timezone type.
And yet, you keep emphasizing "rescheduling" in relation to UTC instead of local time. We already know that DST changes changes the underlying absolute time in UTC. And that's the very reason why you cannot store a future datetime as UTC!
Here's a trick question to put your advice about storing future appointments as UTC to the test:
You want to save a datetime for the New York Times Square midnight countdown to ring in the New Year on December 31, 2018 @ 11:59:45pm. As far as the user is concerned, his/her brain thinks in terms of local wall clock time and therefore, that would be 2018-12-31 23:59:45 ET. (Notice it is "ET" and not "EST" or "EDT")
Do you think you can save that user-specified datetime to the database as UTC?
Do you think it's 2019-01-01 04:59:45UTC ? (Wrong answer.)
Do you think it's 2019-01-01 03:59:45UTC ? (Wrong answer.)
If you don't see why both of those UTC choices are incorrect, please study the previous posts.
To recap the problems with UTC:
-- you don't know in 2016 what future UTC timestamp to write to the database. The user doesn't know either. Nobody knows. It depends on what the government does in the next 3 years.
-- UTC implies scientific precision and writing it to the database for future datetimes will incorrectly advertise that you have the clairvoyance about future rules. You don't.
-- UTC is correct abstraction level for past events (server logs, audit logs) and future non-human generated scientific datetimes such as moon phases and solar eclipses. UTC is the incorrect abstraction level for human generated appointments' datetimes.
Attempting to save a socially-constructed future "wall-clock" datetime as UTC is throwing away information the user gave you. Stop advising people to do that.
I think I see the confusion here. If you went to a group of people and said the movie you were all going to was rescheduled from 11pm UTC to 10pm UTC because of DST you'd get a bunch of "Huh?" and "What local time was it rescheduled to?" You'd answer it was rescheduled from 6pm to 6pm local time. You'd get a bunch of laughs at your "geek humour" while they secretly thought you were nuts. :)
Social events like meetings, movies, etc. are not considered rescheduled when DST starts/stops or the TZ rules get changed.
If you stored the event as UTC you'd have to alter your database when DST starts/stops or the TZ rules changed (is your system going to compare the old and new rules automatically now?).
What does that mean to reschedule? Run a SQL batch job on the database to shift the UTC times by 1 hour?!? Which rows? All of them? Or the rows for a particular TZ? (Better make sure that SQL WHERE clause is error free.) You're just recreating the ambiguity problem but from a different direction.
The issue you keep missing is the UTC is ambiguous when attempting to store the scheduling intentions of the user. If the user wants to store a future socially-constructed datetime, storing it purely as UTC will throw away information.