[Avernar]

We don't agree. It was not rescheduled in reality. Your system would have said it was rescheduled to 7pm Toronto time while in reality the event would still be 6pm Tronto time. The people using your site/app/whatever would be an hour late.

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.

[halostatue]

I would go as far to say that the timezone stored should be a named, geographically-based timezone (e.g., America/New York or Canada/Eastern) as opposed to a timezone offset. (If you store the timezone as EDT or EST, you have still encoded -0400 or -0500.)

[Avernar]

The postgres documentations says exactly that. Other databases might do something else so it's best to read the documentation.

[feld]

but a DST change is a government-mandated rescheduling of the entire lives of its citizens within that jurisdiction :-)

[jasode]

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.