A lot of implementation are actually based on an ISO draft which changed in final release. But most dev do not have access to the spec. For example, timezone can only be specified as offset in the standard, while implementations accept name.
Globally avoid ISO for software, it is non free crap.
Also, do not use those standard for dates with timezone in the future. Use wall time/date and location. As timezone can change way more often than you think.
Of course, when preparing queries against the API, you may need a helper to build valid timestamps. But this is mostly relevant to the discovery phase which isn't automated. And textual dates also have drawbacks, for instance the need to encode it when used a an URL parameter.
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.