Why would you ever want anything to do with timezones in an API? Even for appointments, it's still a timestamp. Timezone should be applied the very last moment, as part of date formatting for output on the client.
If you allow your users to create appointments this much in advance and then they miss them, it's a UX problem, not an API design problem.
In the example in the post you’re replying to, the time zone change means the time stamp would be wrong by an hour. This doesn’t mean that people should show up an hour earlier or later than initially intended!
Timezone isn't a simple constant offset either. For places that use DST, any decent date library would take that into account. If you entered a date in summer while it's winter, it would still result in a correct unixtime.
It's a necessarily manual process and it creates a lot of confusion either way. And it's sufficiently rare to ignore. And these changes tend to be announced in advance.
And we've had examples in the past years of this happening with only weeks of notice, so no, it's not something that never happens.
But who cares. We told you, that there are valid use-cases where timestamps are not the best solution and brought examples. If you don't want to see them, it is your loss.