Example: in November you create an appointment in 6 months at 15h, but then your government decides, to not use summer time next year.
If you use timestamps your appointment will be wrong by one hour (humans tend to keep the 15h).
In general, I am a huge fan of timestamps, but I think it is good to know where they have their limits.
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.