On Mon, Dec 05, 2022 at 01:24:03PM +0000, Kent Watsen wrote: > Thanks for this update Juergen. I was just thinking this morning to ping you > on it. > > > ietf-yang-types: > > 1) The table in the "Overview" section needs to reflect new names (e.g., > s/date/date-with-zone-offset/)
Fixed. > 2) The "revision" statement needs to reflect new names (e.g., > s/with-zone/with-zone-offset/) I think the correct names are listed in the revision statement. > 3) There are two "time-with-zone-offset" typedefs (one should be > "time-without-zone-offset"?) No, I only see one. > 4) Is the "-offset" postfix needed? Or maybe remove the "-zone" part and > only have "-offset"? As noted on a private communication, I looked at what some of the more modern programming language libraries do. So let me shre this here: * Python (datetime) They distinguish 'aware' and 'naive' dates. Date and time objects may be categorized as "aware" or "naive" depending on whether or not they include timezone information. [...] An aware object represents a specific moment in time that is not open to interpretation. [...] For applications requiring aware objects, datetime and time objects have an optional time zone information attribute, tzinfo, that can be set to an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether daylight saving time is in effect. Note that there is both a zone offset and a zone name. Note that a zone name may resolve to different offsets depending on the timezone rules in effect at a given point in time. * Rust (chrono) They also distinguish between aware and naive: Chrono is timezone-aware by default, with separate timezone-naive types. [...] DateTime is timezone-aware and must be constructed from the TimeZone object, which defines how the local date is converted to and back from the UTC date. There are three well-known TimeZone implementations [...]. My reading of their documentation is that their TimeZone object essentially resolves to an offset, not a timezone name. In some contexts, it may be useful to think in terms of 2022-12-05@[Europe/Berlin] rather than 2022-12-05+01:00 (in particular if you keep daylight saving times in your mind or changes of offsets) and to be clear that we currently only model offsets, I decided for the longer and more explicit name date-with-zone-offset (as there was some push towards longer and more precise type names). For interested parties, there is also work in the IETF on adding names to the RFC3339 format: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ They discuss formats like 2022-07-08T00:14:07+01:00[Europe/Paris] and then go into the details if the name and offset are inconsistent etc. > Ietf-inet-types: > > 1) "*-address-and-prefix" instead of "*-address-with-zone"? He? > 2) no deprecation of the legacy "*-address" types? Since there was no consensus to change (and break) definitions, I thought we agreed to simply make no changes and to keep what we have. /js > PS: Diff2 shows nearly everything changed. Diff1 is correct: > > https://www.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-rfc6991-bis-14.txt > > > Kent // as Shepherd > > > > > On Dec 5, 2022, at 6:28 AM, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Network Modeling WG of the IETF. > > > > Title : Common YANG Data Types > > Author : Jürgen Schönwälder > > Filename : draft-ietf-netmod-rfc6991-bis-14.txt > > Pages : 43 > > Date : 2022-12-05 > > > > Abstract: > > This document defines a collection of common data types to be used > > with the YANG data modeling language. This version of the document > > adds several new type definitions and obsoletes RFC 6991. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-netmod-rfc6991-bis-14.html > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-14 > > > > > > Internet-Drafts are also available by rsync at > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod