DST is handled just fine with dates stored as UTC. Your appointment will be at a frozen moment that can perfectly be reflected by an UTC date and it won’t move. If you put 2019–10–12 14:00:00, when you pass it to PHP DateTime/Carbon, it know that if DST is on or off for this date and will convert it into the right UTC date. Then when you will parse it and restore it as any timezone name (I insist: use timezone name, not timezone offset — see the article on this point because I’m pretty sure your trouble come from using offset instead of name) and this name with check the calendar of the timezone and will calculate both offset AND DST flag so you don’t have to store them manually with the risk of mistake and inaccuracy. Many countries tends to drop the DST so you really should rely on the internal calendar than and store using the only reliable timezone: UTC.

Storing timezone info (to remember what the creator used) is a thing but it does not mean you can’t store the moment itself in UTC so it can be handled with no dependency of an other field.

I ensure you, your case is not a particular case, it’s exactly the one this article is about. And following this method consistently does not cause any trouble with DST, this will not change date for anyone rather he’s in a timezone with different DST than the creator, on the contrary.