This is nothing to do with ISO 8601 though.
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.
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.
Take the UK for another example. The daylight savings dates are actually set by act of parliament. Although they always have fallen in the pattern that everyone knows, for dates in future years beyond the ones they have already set, they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
If it allowed "Africa/Cairo" instead of "+0200" that would be fine.
> they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC
2019-12-23T12:00:00-02:00[America/Sao_Paulo]
Sure, we cant know what unix date it resolves to, but it doesn't matter, because future dates are more of a contract intentionally bound to context that is subject to change.