> How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous.

It's a redundant way of writing 2030-07-01T17:00:00Z which only serves to cause confusion (it misleadingly looks like a local time, but it isn't). TAI or equivalent are useful; symbolic timezones are useful; numeric time offsets are useless and there's no benefit from having them be part of the standard.

> Thus proving that what you want does not exist and cannot exist.

Of course it does; 2030-07-01T18:00 Africa/Casablanca is a real time that humans will have no trouble attending a meeting at, and nor will computers as long as they've been keeping their zone file up to date. All we need is a standard for storing and interchanging it on computers.

It's close enough to be useful, more obvious when you have a big offset like +12.

It's not though, the rarer the edge cases are the more they trip you up. Like how UTF-16 is worse than UTF-8 because it's easier to be fooled into thinking it's a a fixed-width encoding, but it isn't.

+01:00 doesn't fool you into thinking it's somehow tied to a particular city or politics.

But it does. The only reason people ever use it is because they think it's "my timezone", which works until it doesn't.

No one thinks that +01:00 will magically turn into +02:00.

No, the reason people use it is because they don't want to add the timezone offset and want a timestamp that's intuitive.

> No one thinks that +01:00 will magically turn into +02:00

Not consciously. But they think it's always going to match the time on the clock in their office / on their town hall / on their phone. No-one deliberately writes a time in the time offset corresponding to their local winter time for an event that will happen in their local summer time (or vice versa).

> want a timestamp that's intuitive.

I don't know about "intuitive", but they want to write times in their local civil time.

> How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous.

Being unambiguous isn't helpful if it is wrong. It is a very common desire to want to set a meeting based on the local time of a destination. The only future-proof way to store such a time, is to remember the destination and the desired local time. This is the only way the proper moment can be calculated and kept in sync with reality.

The unfortunate fact is, the local time could be altered by decree, in any number of ways, in the interim timespan between setting a reminder, and when it happens.

Even that isn't guaranteed to work, because different sets of people in the same place might have different time zones based on political affiliation. That's rare, but it has happened so it certainly could happen again.

> It may or may not be local time in London, but it's unambiguous.

True, but unfortunately humans only care about local time. Setting a meeting for "6PM London time" is how pretty much the entire world operates. If your app can't deal with that, your app is doing it wrong. The world doesn't care that it isn't "well-defined", as developers we just have to deal with it.

> Thus proving that what you want does not exist and cannot exist.

But it does exist, and many calendar apps operate exactly like that. It just requires them to update their timezone database every few months - which in many cases already happens automatically as part of OS updates.

"2030-07-01T18:00:00+01:00" conveys no more information than "2030-07-01T17:00:00Z". The UTC offset is meaningless because it is impossible to get a timezone from it, so it cannot be fixed in the future. It essentially screams "we tried to do local time and failed".