I find it hard to believe that you can't see how people are obviously using the word "rescheduling" in relation to local wall-clock time. The wall-clock time as the reference point is how everyday people commonly use "reschedule". When we flip DST on and off, nobody says "schools and banks got opening times got rescheduled."
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.
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.