On 2024-04-18, at 15:05, Jürgen Schönwälder <[email protected]> wrote: > > The sedate work is updating RFC 3339 recommending against the use of > the -00:00 notation (since it is not conforming to ISO 8601) and > instead suggests that Z is used for systems in UTC with an unknown > timezone offset.
Correct. (Note the word “recommending”.) > The question is now how we deal with this non-backwards compatible > change of RFC 3339 I’m not an authority on the term “non-backwards compatible”, but we have been very careful to point out that -00:00 is less interoperable, hence deprecated, but not suddenly disallowed. So if -00:00 is interoperable in your ecosystem, you can continue to use it. (You should probably add a note that it is not compatible with other uses of RFC 3339, which already was the case even before we wrote up this fact.) I think 6991bis already is compatible with the other observation in Section 2.2 of RFC-9557-to-be: > … "+00:00", which implies that UTC is the preferred reference point … > that apparently got approved by the IESG and > hence there is believe that the Internet won't break based on the > argument that using Z instead of -00:00 is already common practice. What do YANG implementations do today? How do they handle the fact that RFC 3339 implementations that they may be using may have trouble with -00:00? If this is all unproblematic, I don’t see a need to align with the new recommendation in the updated RFC 3339. (Note that the answer to my question also is relevant for the YANG-CBOR stand-in mechanism [1], which works best if the mapping is deterministic, and therefore currently would produce -00:00 for a timezone-free timestamp.) [1] https://www.ietf.org/archive/id/draft-bormann-cbor-yang-standin-00.html#name-ietf-yang-types-tag-1-date- > If so, do we simply align our definition with the updated version of > RFC 3339? Or do we go an deprecate date-and-time and create a new > definition (and then we deal with the updates of all affected > modules over time)? There are too many modules that use the existing type, adding a choice sounds like a way to create busywork and ultimately interoperability failures. Grüße, Carsten _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
