Change:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.

Discussion:
including but not limited to the calendar system it needs to be represented in. <ins> 1.1. </ins> This document defines an extension syntax for timestamps as specified in RFC3339 that has the following properties:

The format provides a generalized way to attach any additional information to the timestamp. <del> 2. </del> <ins> This document does not address extensions to the format where the semantic result no longer is a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, where changes to the definition of that time zone (e.g., a political decision to enact or rescind daylight savings time) changes the actual time in UTC time. Time given as a "floating time", i.e., a local time without information as to which time zone this local time refers to. The use of time scales different from UTC, such as TAI. However, the additional information provided that augments a fixed timestamp may be sufficient to detect an inconsistency between intention and the actual information given in the timestamp, e.g., between the additional timezone information given and the timezone offset recorded in the timestamp.  For instance, such an inconsistency might arise because of: Political decisions as discussed above, or errors in the applications producing and consuming such a timestamp. While the information available is not generally sufficient to resolve the inconsistency, it may be used to initiate some out of band processing to obtain sufficient information for such a resolution. In order to address some of the requirements implied here, future related specifications might define syntax and semantics of strings similar to RFC3339.  Note that the extension syntax defined in the present document is designed in such a way that it can be useful for such specifications as well. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6. <del> 3. </del> <ins> 2. </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> 3.1. </del> <ins> 2.1. </ins> The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is

In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. <del> 3.2. </del> <ins> 2.2. </ins> Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part

A "suffix-value" is limited to "3*8alphanum". <del> 3.3. </del> <ins> 2.3. </ins> Multi-character namespaces can be registered specifically for use in this format, see iana-cons.  The registration policy requires the

solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. <del> 3.4. </del> <ins> 2.4. </ins> The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext". <del> 3.5. </del> <ins> 2.5. </ins> Here are some examples of Internet extended date/time format.

suffix that can be interpreted by any compatible implementations and ignored otherwise. <del> 4. </del> <ins> 3. </ins> Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char. <del> 5. </del> <ins> 4. </ins> TBD