Why is this the case? Is it some time zone shenanigans?
Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location.
Book me a table at 8, means book me a table in Berlin time at 8, not in San Francisco time at 8.
Same with displaying future dates, you need the context of where.
You can represent time zones with that format. So long as you have a source time zone, target time zone and tzdata you can convert any time accounting for all the particularities of any particular zone.
> 2036-11-13 04:00:00 Africa/Cairo
Is fine
> 2036-11-13 04:00:00 +0200
Is not, as the rules around moving from +3 to +2 may well have changed by them.
And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.
If my locale decides in 2026 to opt out of daylight savings time and not use it anymore -- it does not mean my appointment is now at 1:00pm instead. My appointment is still at April 12th 2027 at 2:00pm. But if I had saved it as a prediction of a UTC time in ISO 8601, then the system would think my appointment was now at 1:00pm.
This is why it has to do with dates being in the future. A past date-time can be converted to a UTC time represneted in ISO8601 that will not ever change (if it was converted properly).
I'm not sure where you got restaurants from -- you are the first person in this thread to mention restaurants? That is one use case for storing dates and times in the future, but certainly not the only one! There are of course some where the time zone is not "obvious". You realize there is software that's used for things other than restaurant orders and reservations, right? (Also I can imagine a restaurant that's a mobile food truck in an area near a timezone border...)
You speak very authoritatively and combatively about something I think you may not be on the same page about.
Or do you mean that ISO 8601 doesn't work but RFC 3339 does work or some other updated ISO/RFC format?
Someone else has mentioned RFC 9557.
So you might be able to deal with it with 8601 for past dates and 9557 for future.
