[seanhunter]

That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain.

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.

[iso1631]

ISO 8601 only allows timezones as offsets, not as locations.

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

[phiresky]

There's an extension to ISO8601 that fixes this and is starting to become supported in libraries:

    2019-12-23T12:00:00-02:00[America/Sao_Paulo]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[jrochkind1]

The fact that ISO8601 does not store time zones (only fixed UTC offsets, which is not the same thing) obviously has something to do with ISO8601. I'm not sure what you're going on about?

[seanhunter]

I’m saying the problem is the time zone, not the fixed offset. The fixed offset always means a specific time (which may or may not be the time in a particular place, due to problems with the definition of time zones). Times for dates in the future are a problem due to time zones, not due to offsets. If you know the offset, the time is exactly specified.