Hi Kent, thank you for this feedback.
>> (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. > > In all applications I’ve worked on, time is encoded in UTC using the ‘Z’ > suffix on the wire, and as UTC in the database. The presentation-layer > always maps the UTC to/from local-time. So essentially, you already are in RFC 9557 land: You are seeing the use of “Z” in a situation where there really is no information about the local time that might apply to this timestamp. RFC 3339/6991 would have used -00:00 for that, and RFC 9557 uses Z. So actually, there may be two kinds of backwards compatibility here: (1) backwards compatibility to what the spec says (RFC 3339/6991 and the two buckets for -00:00 and for Z/+00:00) (2) backwards compatibility to what implementations and common operational use actually imply (RFC 9557 and the two buckets for Z and +00:00, where only the Z bucket is actually employed). Interesting. So does anyone have an example where implementations or operational practices actually care about that second piece of information in a timestamp, namely the relationship to some local-time offset? Grüße, Carsten _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
