[gpvos]

No.

It is in fact best to store the local time and the location (i.e., not "+01:00", but for example "Europe/Amsterdam"). Not UTC with or without time zone. For example, if you have an appointment in the future, and the time zone or daylight savings time rules change, this is the only way that the appointment can still be at the correct moment. And time zone rules do change.

And this way you can still represent absolute UTC time if you wish. With another representation, you cannot represent human-society time, which is often what you actually want.

[vbit]

Good point. However this is a specific use case requiring future local time, and as you mention, even TZ aware local time fails here. In this case you cannot come up with a guaranteed physical time in the future that the event will take place.

IOW, I think storing local time and location as a rule is not a good idea. The rule should be to use UTC and store location if needed. Only if that doesn't work (e.g. '5 minutes after the game is over') come up with some other representation.

[gpvos]

One extra thing (one could call it a weakness) with the local+location scheme is that you will need to have a way to distinguish the "repeated" hour after daylight savings time sets the clock backward one hour from the hour before it.