I store my data in UTC anyway. BUT why not include the timezone in the timestamp? Then in your example you can change the server's timezone with no disruption...
I don't think there is an unambiguous way to represent time zones. Time zones are a creation of law and convention. They change, and have changed, over time.
For dates in the future, you need to store local time, the timezone name, and the calculated offset for that time. When the database changes, you need to check if the offset changes, and if so, think hard about what that means. Also, some future events are more appropriately scheduled for local time wherever the person happens to be, which is tricky too.
UTC±hh:mm
1. Know when a globally ordered even happens. Using UTC or local time with offsets satisfies this requirement.
2. Know when an event occurred in local time, for example movie show times (I can't know what time to print on the ticket without getting the theater's time zone when passed in UTC). UTC does not solve this problem, but local time with offsets works.
Example of when I wrote this comment:
$ date -u +"%Y-%m-%dT%H:%M:%SZ"
2018-02-08T16:17:48Z
$ date +%FT%T%z
2018-02-08T08:17:48-0800
Finally, many client-side requests for dates should be in local wall time without an offset or UTC. Of course this is application dependent, but I've seen this go wrong a few times.
Please share other ideas/suggestions if you have them.