Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322

I am also going to strongly +1 John here.

At this point, the only question I would consider in a protocol is the
choice of UTC or TAI.

Unfortunately, the method of platform handling of UTC means that all date
time values recorded in electronic documents are inherently ambiguous, a
state of affairs that will persist until the cretinous notion of leap
seconds is done away with.

On Tue, Apr 13, 2021 at 4:06 PM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)"
> <elear=40cisco.com@dmarc.ietf.org> wrote:
>
> > The question is whether you need something that is easy to
> > parse or something that is human readable and can be
> > localized.  It SEEMs that this draft is intended to be human
> > readable, and so 5322 doesn't seem out of bounds.
>
> I suggest that even for reading by humans in 2021 --as distinct
> from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year
> ordering)-- the 5322 dates are not easy to understand and use...
> at least unless one is an English speaker on this side of the
> pond.  It was quite wise at the time to spell out the month
> name, thereby eliminating the ambiguity associated with, e.g.,
> 5/10/1977, but still bad news for someone who might think the
> fourth month in the Gregorian calendar is, e.g., апреля,
> أبريل , or 四月.
>
> So I would argue that, for new protocols or data structures in
> this increasingly global/ international Internet, and even for
> elements visible to humans, sticking as close to ISO 8601 as
> possible (with minimal profiling) is the Right Thing to Do.
> Much too late now to change the 822/5322 format, turning
> supplemental protocols for email into a gray area, but, for new
> work, ISO 8601 formats are not just easier to parse but easier
> to understand globally and in an unambiguous way.
>
> Just my opinion, of course.
>
>
>     john
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>