--On Wednesday, October 19, 2022 16:11 +0000 Edward Welbourne
<[email protected]> wrote:
> On Tuesday, October 18, 2022 18:13 +0200 Carsten Bormann
> <[email protected]> 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
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
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
