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
>> 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)
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.
>> 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".
K.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
