[mason55]

A better answer is to use time+locale for things that are supposed to happen in the future and UTC for things that happened in the past.

The reason is that things that happened in the past will have a specific moment on the arrow of time at which they happened, and UTC is as good as anything else for putting a consistent label on the arrow of time.

But, for things that are going to happen in the future, you have no way of knowing if two "time labels" that right now point to the same moment on the arrow of time might have some change that causes them to point to different moments. In this case UTC removes the ambiguity about the timezone that the time is in, but it adds ambiguity about which moment in time you're really talking about.

Let's say you want to schedule something for 9pm local time (UTC-3). So you schedule it for midnight UTC. Then your timezone shifts to UTC-2 and your appointment moves to 10pm. That's likely not at all what you intended. It's also why you need to pick a "master" timezone when you're sending invites to multiple timezones and let the rest of the times be derived from the "single source of truth" time.

[stefan_]

This heuristic obviously doesn't work. I build a factory in a strategy game. It is going to take 10h. The timezone shifts; should it take longer, shorter, the same? Obviously the same.

You still need to use your brain and careful UI design. Things that a user scheduled to happen at a specific local time need to store the relevant timezone, implicitly or explicitly.