[laut]

If the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing.

If you actually look at what happens when timezone laws change, people continue to anchor to their local times.

[feld]

Congratulations you literally just rescheduled the event. This is not a timezone issue. The date should still be stored as UTC.

[jasode]

>Congratulations you literally just rescheduled the event.

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.

[Avernar]

Wrong. Let's say an event is scheduled for 6pm daily in Toronto (EST -0500). You store it as 11pm UTC. Now eventually we switch to EDT -0400 due to DST. Now your system will say the event is at 7pm local time.

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.

[feld]

The event was literally moved to a different time UTC. I'm glad we agreed that it was rescheduled.

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.

[Avernar]

> The event was literally moved to a different time UTC. I'm glad we agreed that it was rescheduled.

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?).

[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.