Sometimes timezones or the like change. So for future dates, those textual represations are probably better.

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.

> Sometimes timezones or the like change.

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.

Why do you say appointments are a time stamp? They are made with humans in mind, people dealing with a local time zone.

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!

Because they are a timestamp. In an overwhelming majority of cases when you're going to deal with time in software, it's a timestamp. Timezones are a client's concern. You ask the user to input the time in their local timezone, then convert that to unixtime and send it to the server.

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.

Do you intentionally just ignore the point made about timezone changes?

Well, how do operating systems handle this sort of stuff? With updates. When it's at all possible to update. There are many devices that don't receive any updates at all any more. There are some devices that weren't designed to be updatable to begin with.

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.

This argument is complete non-sense (just because a device doesn't receive software updates it doesn't mean it can't receive date/time updates).

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.

So you'd rather push out an update every time for your app to rewrite the times it has stored to match the timezone change, instead of "just" updating the timezone database and the app automatically doing the right thing?

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.