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. 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. 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
