I will leave the definition of date-and-time as is. When the definition was created, we followed RFC 3339:
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC 3339 kind of suggested that "Z" and "+00:00" mean the same, so we made "-00:00" the canonical format if the offset to local time is unknown and we can't change the canonical format. It is what it is. The WG may consider to create a new YANG module for date and time types and there we can define a date-and-time replacement with new semantics and we can also provide types supporting some of the good stuff in RFC 9557 (in particular referring to time zone names instead of just static offsets). /js On Tue, Jun 04, 2024 at 07:41:43AM +0200, Carsten Bormann wrote: > 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 > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
