On Fri, Dec 09, 2022 at 04:00:08PM +0000, Kent Watsen wrote: > > Hi Juergen, > > > >> 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. > > I see. Then there are three variants? > > foo-no-zone > foo-zone-with-zone-offset > foo-zone-with-zone-name > > Where "foo" is "date" and "time". To complete the set, are these two > definitions missing? > > yang:date-with-zone-name > yang:time-with-zone-name
Nobody has asked for a 'name' version yet. I just wanted to use this example that demonstrate that it is hard to future proof name choices. (And we also do not distinguish between mandatory and optional components, our date-and-time type really should be named date-and-time-with-optional-zone-offset.) > >>>> 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). > > Fine. > > > >>>> 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? > > And here we are. It appears the one side is being vocal, and the other side > not at all. I have no appetite to delay this the draft any longer. > Disregard. > > > > 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. > > I'd forgotten your exchange with Tom Petch. Disregard. > > > Let's close on the thread at top and then exit the document from the working > group. > > > Kent // co-chair and shepherd > -- 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
