Andy Bierman <a...@yumaworks.com> wrote: > On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder < > j.schoenwael...@jacobs-university.de> wrote: > > > On Mon, Dec 05, 2022 at 08:19:12PM +0000, Kent Watsen wrote: > > > > > > > > > Hi Juergen, > > > > > > > > > > > > >> 3) There are two "time-with-zone-offset" typedefs (one should be > > "time-without-zone-offset"?) > > > > > > > > No, I only see one. > > > > > > My bad, I didn't see the subtype. > > > > > > But I may've been thrown off by the following "no-zone" types...should > > they be named consistently? > > > > > > - date-no-zone --> date-no-zone-offset or date-without-zone-offset > > > - time-no-zone --> time-no-zone-offset or time-without-zone-offset > > > > The 'no-zone' indicates no zone information, neither by offset nor by zone > > name. > > > > > > > > >> 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. > > > > > > > > > "Offsets" are good (regional names would be too involved, IMO) > > > > Zone offsets change for certain locations regularly (daylight saving > > times) and this is why many user facing interfaces configure time zone > > locations by letting the user select a zone name like Europe/London > > that then maps via the IANA timezone database rules to the specific > > zone offsets. > > > > > My thought is only to shorten the names. e.g., time-with-zone-offset > > --> time-with-offset? If it doesn't make sense, semantically, then no > > worries keeping as is. > > > > Some what descriptive names, some want names to be future proof, > > others want names that match names used elsewhere, then some prefer > > short names, its obviously difficult. Initially we had date (with an > > optional zone offset) plus date-no-zone without it. This matchedthe > > good old date-and-time (which also has an optional zone offset). > > > > > >> 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. > > > > > > > > > This was discussed at 115, on slide #8 here: > > https://datatracker.ietf.org/meeting/115/materials/slides-115-netmod-1-session-intro-wg-status-00 > > . > > > > > > Lou and I are trying to break the logjam, and no one objected, so it's > > fine to proceed now. What I'd do: > > > > > > 1) rename the existing definitions to the new name. > > > 2) recreate the old definitions as having the "type" of the new > > definitions and "status deprecated". > > > > > > > Consensus is determined on the mailing list, no? > > > > I am sorry that I missed decisions taken in London by not reading the > > slides. So I should also remove the language-tag type I guess. > > > > And then I write that ip-address was deprecated because some were > > confused by the name? Well, if this is how we make progress... > > > > > > Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the > most disruptive > change to YANG that one could make. I am not sure there are real > operational problems > that warrant this change.
I fully agree. > > A type name cannot be changed. > A new name can be introduced so there are 2 types that do the same thing. > IMO this will increase the overall confusion, and not help in any way. +1 /martin > > Making this worse is the fact that status "deprecated" is incorrectly > defined in YANG 1.1 > because it means the same as "obsolete". It also adds to the perception > that the IETF > cannot provide stable YANG modules to the world. > > > /js > > > > > Andy > > > > -- > > 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 > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
