Change:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.

Discussion:
RFC3339 for representing additional information including a time zone. <ins> It updates RFC3339 in the specific interpretation of the local offset "Z", which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see update. </ins> 1. Dates and times are used in a very diverse set of internet

2. <ins> RFC3339 states that an offset given as "Z" or "+00:00" implies that "UTC is the preferred reference point for the specified time".  The offset "-00:00" is provided as a way to express that "the time in UTC is known, but the offset to local time is unknown". This convention mirrors a similar convention for date/time information in email headers, described in RFC5322 and introduced earlier in RFC2822.  The latter convention is in actual use, while the former always was handicapped by the fact that ISO8601 does not actually allow "-00:00". Implementations that needed to express the semantics of "-00:00" therefore tended to use "Z" as a "neutral" offset instead. This specification updates RFC3339, aligning it with the actual practice of interpreting the local offset "Z": this is no longer understood to "imply that UTC is the preferred reference point for the specified time". Note that the semantics of the local offset "+00:00" is not updated; this retains the implication that UTC is the preferred reference point for the specified time. Note also that the fact that ISO8601 does not allow "-00:00" as a local offset reduces the level of interoperability that can be achieved in using this feature; the present specification however does not formally deprecate this syntax.  For the intents and purposes of the present specification, the local offset "Z" can be used in its place. 3. </ins> This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols. <del> 2.1. </del> <ins> 3.1. </ins> The format is intended to allow implementations to specify additional important information in addition to the bare timestamp.

implementations MUST give precedence to whichever value is positioned first. <del> 2.2. </del> <ins> 3.2. </ins> Actual suffix tag keys are registered by supplying the information specified in this section.  This information is modeled after that

BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented. <del> 2.3. </del> <ins> 3.3. </ins> For the format defined here, suffix tags are always

IXDTF strings such as: are internally inconsistent, as Europe/Paris does not use a time zone <del> 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: </del> <ins> 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: </ins> Similar with: <del> However, </del> <ins> (assuming that the recipient does not understand the suffix key "knort"). </ins> <del> all have an internal inconsistency or an unrecognized suffix key/ value, so a recipient MUST treat the IXDTF string as erroneous. </del> <ins> In contrast to this elective use of a suffix tag, each have an internal inconsistency or an unrecognized suffix key/ value that are marked as critical, so a recipient MUST treat the IXDTF string as erroneous. </ins> Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking

reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical. <del> 3. </del> <ins> 3.4. An RFC 3339 timestamp can contain a "time-offset" value that indicates the offset between local time and UTC (see RFC3339, noting that update of the present specification updates RFC3339). The information given in such a "time-offset" value can be inconsistent with the information provided in a time zone suffix for an IXDTF timestamp. For example, a calendar application could store an IXDTF string representing a far-future meeting in a particular time zone.  If that time zone's definition is subsequently changed to abolish Daylight Saving Time, IXDTF strings that were originally consistent may now be inconsistent. In case of inconsistent "time-offset" and time zone suffix, if the critical flag is used on the time zone suffix, an application MUST act on the inconsistency.  If the critical flag is not used, it MAY act on the inconsistency.  Acting on the inconsistency may involve rejecting the timestamp, or resolving the inconsistency via additional information such as user input and/or programmed behavior. For example, the IXDTF timestamps in example-inconsistent represent 00:14:07 UTC, indicating a local time with a "time-offset" of +00:00. However, because Europe/London used offset +01:00 in July 2022, the timestamps are inconsistent: As per RFC3339 as updated by update, IXDTF timestamps may also forego indicating local time information in their RFC3339 part.  The IXDTF timestamps in example-consistent (which represent the same instant in time as the strings in example-inconsistent) are not inconsistent because they do not assert any particular local time nor local offset in their RFC3339 part.  Instead, applications that receive these strings can base their local offset and local time calculations on the time zone suffix given, i.e., using the Europe/London time zone rules. </ins> <del> 3.1. </del> <ins> 4. 4.1. </ins> The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix.

but does not include an equals sign.  This special case is only available for time zone tags. <del> 3.2. </del> <ins> 4.2. </ins> Here are some examples of Internet Extended Date/Time Format (IXDTF).

interpreted by implementations that take part in the controlled experiment making use of these tag keys. <del> 4. </del> <ins> 5. </ins> Out of the possible suffix keys, the suffix key "u-ca" is allocated to indicate the calendar in which the date/time is preferably

this suffix key is as defined by the CLDR data for TR35.  At the time of writing, this information is collected in CLDR-CALENDAR. <del> 5. </del> <ins> 6. </ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the

second case, the expert is instructed to ascertain that a basic specification does exist, even if not complete or published yet. <del> 6. </del> <ins> 7. </ins> TBD