>> 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)?
A third approach might be to place the emphasis on backwards compatibility you’d expect from YANG and declare 6991bis an island of resistance against the update made in Section 2 of RFC 9557. So you stick with -00:00 for the canonical form of a timestamp with an unknown relationship to local time (where RFC 9557 uses Z), avoid Z, and continue to use +00:00 for explicit Reykjavik/Monrovia. After all, the libraries that will be used to generate and ingest date-and-time can be custom for YANG; there is probably less expectation that John Doe will hack together a YANG library based on JavaScript without paying explicit attention to this issue. If you do have a RFC 9557 library, you just replace all -00:00 with Z before ingestion, and all Z with -00:00 after generation. Grüße, Carsten (1) In YANG-CBOR, we of course want to use stand-in binary values [1], so we care only as much as we need in order to support conversion between binary stand-ins and the textual conventions. [1]: https://www.ietf.org/archive/id/draft-bormann-cbor-yang-standin-00.html (2) I’d love to know what kinds of timestamps real YANG implementations send here — do they really pollute their timestamps with local-time offset information? Does any recipient actually care about the local-time relation information encoded here? I’d expect everything to be -00:00, but then I’m a utilitarian. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
