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

I am also going to +1 John's suggestion. ISO 8601 and Zulu time are highly desirable in new standards.

I will also ask how many digits are needed for sub-second precision.

The Precision Time Protocol (IEEE 1588-2019) gets to microsecond and possibly nanosecond range (to be fair, I have not read the 2019 additions).

Some of the Deep Space Network seems to express measurements with very fine grained values and small angles (11 nrad).

Although the ABNF in RFC 3339 hints at sub-second values, it does not actually use examples.

Twelve digits after the decimal point expresses pico seconds which is just silly and unrealistic at present, but micro seconds seem plausible in many contexts. If new standards are forward looking, then the expression should possibly be considered.
(I do not see a need to consider femto, atto, zepto, or yacto seconds at the present time.)

YYYY-MM-DDThh:mm:ss.nnnnnnnnnnnnZ

Fwiw: I agree that leap seconds is a pain.

        Be safe, stay healthy,
        -- Mark

> On Apr 14, 2021, at 12:36 PM, Phillip Hallam-Baker <ietf@hallambaker.com> wrote:
> 
> 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 <mailto:john-ietf@jck.com>> wrote:
> 
> 
> --On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)"
> <elear=40cisco.com@dmarc.ietf.org <mailto: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 <mailto:art@ietf.org>
> https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag