> A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (which at that point is on +2:00), so you are begging for data corruption. The whole concept of "inconsistent timestamps" should not exist!
The spec states you would ignore the [Europe/Paris] in that case, no? Not either or?
Also, the specification states you can opt in to the behavior that you are asking for by marking it as critical?
No, the spec states that you MAY resolve the inconsistency. For non-critical tags it would be acceptable to interpret it as either "2022-07-08T00:14:07+01:00", "2022-07-08T00:14:07[Europe/Paris]", throw an error, or ask the user for clarification.
Throwing an error is the only thing you can reasonably do because you're dealing with invalid data. Yes, there is the "critical" flag, but that's not helping much. There should not be an opt-in "don't corrupt my data" flag because there aren't any scenarios where you don't want it to be set.
Having the option with an opt-in flag should never happen. Having it with a mandatory critical flag is a bad idea, but not horrible. But if you're designing a new standard, why not just avoid the whole problem altogether by simply not introducing the whole concept of inconsistent timestamps in the first place?
The spec states you would ignore the [Europe/Paris] in that case, no? Not either or?
Also, the specification states you can opt in to the behavior that you are asking for by marking it as critical?
2022-07-08T00:14:07+01:00[!Europe/Paris]