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