Original text:
BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented.  3. 3.1.

Reviewer comments:
(Elective, ignore option if not understood) (Critical, must understand/must reject date if not understood)
It's possible for a timestamp's offset to conflict with the timezone extension. Usually this is caused by a programmer bug where the wrong offset or the wrong timezone was put in the string. However, in rare cases changes to TZDB rules can cause a conflict. Assume was stored by a program running in 2018 using TZDB rules in effect that time. But after Brazil's time zone rules were changed in April 2019, the correct offset for that point in time is now . How should the SEDATE standard deal with conflicts like this? UPDATE 2022-03-21: Our (Temporal team's) understanding is that the WG wants the new standard to be a strict superset of RFC 3339, which implies that the timestamp should be considered a higher priority than the bracketed time zone extension. Using the Brazil example above, a timezone-aware implementation using the current TZDB should interpret (now the wrong offset) as the same timestamp but a different local time: . If this understanding is correct, then here's strawman text for discussion: Our assumption is that a later standard (maybe the same one that will standardize floating times?) may provide a way to encode a different conflict-resolution preference into timestamp strings. Note that the offset exception is needed because, as noted in , many applications (and libraries like URL) use to mean "I don't know the local offset". ORIGINAL CONTENT (LONG) Here's how Temporal handles conflicts like this in our current API design: A "conflict" means that the date and time shown in the timestamp is not valid for the time zone in brackets, according to the TZDB rules that the parsing program is using. If there's a conflict, by default an exception is thrown when parsing. The offset will never cause a conflict, because Temporal interprets as a "null time zone" that is not asserting anything about the local date or local time in a real place on earth. Therefore, the bracketed time zone will take precedence if a offset is used. Callers can optionally override the behaviors above by calling the parsing function using an optional parameter that controls parsing behavior: will make the offset win, will make the bracketed extension win, and is the default behavior. We'd prefer the standardized behavior to be compatible with the current Temporal implementation described above. But if we must make a change, then we'd be OK to change the default behavior from "throw an exception in case of conflict" to "non-Z offsets always win". We think that "throw on conflict" is the best default behavior because it helps the developer detect conflicts which would otherwise go unnoticed by the 99% of developers who'll never anticipate possible conflicts. But we also acknowledge valid arguments in favor of an "offset wins by default" behavior. We WOULD NOT be OK with a behavior that always rejects Z offsets with bracketed time zones, because that would prevent creating strings where the original local date/time is unknown. This "don't know the offset" limitation is very common for timestamps stored in a relational database and other systems that only store a "time since epoch" value without an offset. In those cases, there's no clear alternative to using a Z offset in the string. We WOULD NOT be OK with a change that prevented Temporal from providing callers with an option (see (4) above) to override the default conflict-resolution behavior. The ability for callers to have an opt-in way to decide conflict resolution behavior is important because, as discussed above in the Brazil example, in rare cases valid strings will later become conflicting. In many cases, it's not practical for these previously-stored strings to be updated. (For example, they may be stored in a database owned by someone else.) So programmers need to have a way to deal with those kinds of strings if they receive them.
NAME and I discussed this issue tonight in context of recent discussions on the WG, and I just updated the OP to simplify and and clarify Temporal's requests to align with the latest WG discussions. Apologies for late-breaking updates, but hopefully it should simplify the discussion in the real-time meeting.
(see also discussion under )
While most of this is covered by the new Section 2, we could discuss what is remaining under . RFC 3339 says that the offset -00:00 should be used when the local offset is unknown. . Unknown Local Offset Convention If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE ] describes a similar convention for email. However, my understanding is that many (most? almost all?) applications and libraries ignore the standard's advice and instead use Z, not -00:00, when the local offset is unknown. For example, URL uses Z even though it does not know the local offset because its data model is only a single time-since-epoch value. Example: import URL; class Main { public static void main(String[] args) { Instant instant = URL("2017-06-16T21:25:37.258Z"); URL(instant.toString()); // => 2017-06-16T21:25:37.258Z } } Is my assumption correct that most applications use Z when -00:00 would be more correct according to the standard? If so, do you know why -00:00 never became popular? Cheers, Justin

Revised text:
BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented. <ins> 2.3. For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) Without further indication, they are also : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. A suffix tag may also indicate that it is : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). Internet Date/Time Format strings such as: are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for "+00:00"), nor a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: Similar with: However, all have an internal inconsistency or an unrecognized suffix key/ value, so a recipient MUST treat the Internet Date/Time Format string as erroneous. Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking the user how to resolve the inconsistency.  It means it is not required to do so with elective suffix tags, but is required to reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical. </ins> 3. 3.1.