[Ntp] Antw: [EXT] Re: [Sedate] [art] [Cbor] Two specifications on timestamps nearing WGLC

[Ulrich Windl <[e-mail]>]

>>> John C Klensin <[e-mail]> schrieb am 19.10.2022 um 19:58 in
Nachricht
<2BE4AC74DD211BF113444CAE@PSB>:

> 
> ‑‑On Wednesday, October 19, 2022 16:11 +0000 Edward Welbourne
> <[e-mail]> wrote:
> 
>> On Tuesday, October 18, 2022 18:13 +0200 Carsten Bormann
>> <[e-mail]> wrote:
>>>> ...
>>>> Whoever invented the adaptation of ‑00:00 to the RFC 3339
>>>> format did not have a copy of ISO 8601, did not bother to
>>>> look, or didn't think that the resulting incompatibility
>>>> would be a problem in practice. Turns out, it actually is.
>> 
>> John C Klensin (19 October 2022 17:07) replied (inter alia):
>>> (3) We are, however, supposed to be about interoperability and
>>> reality.
>> 
>> Speaking of which, while I realise other software may have
>> implemented ISO 8601 carefully enough to reject ‑00:00, I note
>> that the Qt framework (for C++ development) has a QDateTime
>> whose ISO 8601 format handling blithely accepts ‑0000 or
>> ‑00:00 if given it, while consistently producing +00:00.  I
>> shall not be hugely surprised if plenty of other real‑world
>> parsers and serializers of "ISO 8601" have similarly lenient
>> parsing but conformant serialization.
>> 
>> The present discussion was the first I ever heard of ‑00:00
>> having a special meaning in e‑mail headers, or of ISO 8601
>> forbidding it; and I strongly suspect many other implementors
>> of these specs are in the same position.
>> 
>> None of which is an attempt to talk anyone out of fixing the
>> problem, but hopefully it can give a sense of perspective to
>> how dire it might be. Let us all remember the words on the
>> cover of the hitch‑hiker's guide to the galaxy,
> 
> Eddy,
> 
> Thanks for the additional calibration.  Sadly, I find none of it
> surprising.
> 
> It is why I have been pushing for some time for minimizing the
> number of places where the same thing (or nearly so) is defined.
> As soon as we have  definitions in different places, even if
> they start off identical, there is an opportunity for divergence
> as things evolve.  That can occur even if syntax remains the
> same if interpretations or other semantics diverge.  If we have
> to have differences, I think it is important to be explicit
> about them and reference the other places. For example, that
> special interpretation of ‑0000 in the email specs is not, IMO,
> inherently a problem.  But, if you are interested and involved
> in such things, the fact that you had not been aware of it
> reflects badly on standards‑writers.  And, incidentally, your
> writing "‑00:00 having a special meaning in e‑mail headers"
> above, when "‑00:00" is prohibited in email headers but "‑0000"
> is specified there but disallowed by RFC 3339, may be another
> symptom of the problem(s).
> 
> In case anyone has not thought about it this way, the problems
> are also far more severe for SEDATE or anything having to deal
> with calendaring than they are for email.   The only place
> date‑times are used in the email specs is for time stamps where
> they record the date and time something happened.  I may write
> "next week" in prose in an email body, but the ambiguities
> associated with that have been moderately well understood for
> centuries.  It may not be clear whether that is the date and
> time where a writer or server is located or in some other zone
> (typically UTC), but it is a fixed time and event.  As soon as
> one moves into a world in which one needs to be able to talk
> about, e.g., "180 days from now", and even if "same place" is
> implied, there is immediately an issue about whether that is
> however many seconds "180 days" implies or "same time there that
> many days away", which may interact with local time zone
> adjustments (summer time, etc.) at that location, to say nothing
> about possible political/ legislative changes in time zones.  If
> one happens to be located near the zero meridian that is
> additionally important because +00:00 (or "Z", which RFC 3339
> and ISO 8601 appear to believe are synonymous) is different from
> ‑00:00 in those email specs, which is often taken to mean "UTC
> no matter what" such that "NNN time units from now" can be
> expressed in seconds or the like without qualification for local
> practices or politics.  And, IMO, RFC 5322 is not clear enough

Interestingly I found the complement of "-0000" in RFC 5545 (iCalendar, "FORM
#1: DATE WITH LOCAL TIME" (page 33), claiming to be based on [ISO.8601.2004]):
"DATE-TIME values of this type are said to be "floating" and are not bound to
any time zone in particular.  They are used to represent the same hour, minute,
and second value regardless of which time zone is currently being observed. 
For example, an event can be defined that indicates that an individual will be
busy from 11:00 AM to 1:00 PM every day, no matter which time zone the person
is in.  In these cases, a local time can be specified."

> about that, which is why we are having these discussions in two
> rather different WGs, without coordination except by accident
> and whining.
> 
> dire indeed.  I think our aspiration for both the SEDATE and
> EMAILCORE WGs should be to not make things worse, whether we can
> "solve" the problems or not.
> 
>     john
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp