Subject: [saag] Date formats: RFC3339 vs. RFC 5322

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 Apr 2021 14:43:36 -0400

Is there a preference for Internet drafts/RFCs regarding the specific
data/time format to be used?

Right now we are referencing RFC 5322, but there has been feedback
from multiple people that the ISO 8601 format is easier to parse. This
is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11"
that I am working on:
https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4

The options I am asking about are the following:
- RFC 3339 (a profile of ISO 8601)
Example: 2021-04-13T06:50:53-07:00

- RFC 5322, section 3.3
Example: Tue, 13 Apr 2021 06:50:53 -0700

Thanks

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 13 Apr 2021 19:00:17 +0000

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.

> On 13 Apr 2021, at 20:43, Yakov Shafranovich <[email-masked]> wrote:
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Apr 2021 12:04:19 -0700

For use in protocols, I think you'd probably find that most people would
strongly favor the use of 3339 if at all possible.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Apr 2021 14:05:04 -0500

> Example: Tue, 13 Apr 2021 06:50:53 -0700

My very strong preference is for ISO 8601 format dates on account of:

 - it sorts semantically correctly when sorting alphabetically (when
   using Zulu time)

 - anyone can read and write ISO 8601 format dates, and it's easy to
   memorize -- this is not true of any other format

I would further suggest that timezone information for this purpose is
not very useful in this context, and that always using Zulu time would
be best.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Apr 2021 14:19:38 -0500

On Tue, Apr 13, 2021 at 07:00:17PM +0000, Eliot Lear (elear) 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.

English-centric much?  :)

Seriously, RFC 5322 is unnecessarily English centric, and ISO 8601 is
universally understandable.

Nico
--

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 13 Apr 2021 12:30:21 -0700

> Example: Tue, 13 Apr 2021 06:50:53 -0700

Given that the date in that section of that draft is meant to be machine 
parsed, choosing RFC 5322 (neé 822) date formats is a particularly bad 
idea, given the existence of RFC 3339.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Apr 2021 15:01:02 -0500

On Tue, Apr 13, 2021 at 12:30:21PM -0700, Paul Hoffman wrote:
> parsed, choosing RFC 5322 (neé 822) date formats is a particularly bad idea,
> given the existence of RFC 3339.

I mean, strptime() can handle both, and since everything is written in C
(which is why we so badly need security.txt!), that's enough.  But yes,
ISO 8601 is much easier to parse.  And it will be even easier to compare
dates if security.txt ends up using Zulu time, since then plain string
comparison (even memcmp()!) is enough.

Thinking about implementation... I suddenly wonder why security.txt
should have expiration instead of a TTL.  I'm pretty sure what's really
intended is that I not cache security.txt files too long so that they
can be updated.  Indeed, sections 3.5.5 and 6.3 make it clear that this
is about caching.

An optional publication time (ISO 8601), and a required TTL measured in
hours or days would be more than sufficient, and maybe superior to a
notAfter.  Unless the point of `Expires` is also to force the publisher
to keep security.txt up to date.

Implementation-wise, I see a few ways in which I would handle `Expires`
information:

1) Comparison.  E.g., to determine if a security.txt is stale, or to
   sort/index/search archived security.txt files, in which case I'd have
   two choices:

   1a) if the format is ISO 8601 zulu, then format current time then
       string compare,
   1b) parse the `Expires` into local time of day form and compare to
       current time.

   (1a) is simpler, but only works for ISO 8601 Zulu times.

3) Authoring/production of security.txt files, where I only need to
   format time, not parse it.

Clearly it's easier to only have to format time and never have to parse
it.

That said, strptime() and similar are widely available and easy enough
to use, so I do think there's an readability argument to make.  But ISO
8601 is still easier to read than RFC 5322 time, especially for
non-English speakers.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Apr 2021 16:06:10 -0400

--On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)"
<elear=[email-masked]> 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

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 13 Apr 2021 22:58:44 +0200 (CEST)

let me do a wider diversion:

human reading of time and date, was and still is a cause of problems: the 
human readable version, with all its flavours, variants, causes 
headaches... every time we schedule a meeting we need to ensure all do 
understand when it is... 04/07/2021  at 2.30PM  is it the 4th day of July 
2021, or th e 7th date of April? 2.30PM which time zone? DST or not?

So to go back to the point, +1 to John: ISO 8601 is better, also for 
humans!

(the date/time paring code for email gateways I wrote 30+ years ago was 
a set of nested "if" "then" "else" "and" "or" and tables... no thank you.)

On Tue, 13 Apr 2021, John C Klensin wrote:

> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

      PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Apr 2021 14:01:30 -0700

> not very useful in this context, and that always using Zulu time would

thank you

randy

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Apr 2021 15:17:45 -0700 (PDT)

> idea, given the existence of RFC 3339.

Whenever machine parsing enters the picture the other syntax that should be
considered is integer milliseconds since epoch. (This syntax is increasingly
popular in the schemata I encounter.) However, I think there's also a need for
this to be readable. RFC 3339 seems like the right balance to me.

				Ned

---

From: Michael Douglass <[email-masked]>
Date: Tue, 13 Apr 2021 19:08:54 -0400

Even as a UK person I prefer the ISO8601 format

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Apr 2021 21:22:33 -0700

On 4/13/2021 12:19 PM, Nico Williams wrote:
> English-centric much?:)

The RFC5322 date format was not designed for use as extensive as venues 
speaking English.  It's original target for use was restricted only to 
North America (cf, RFC733).

I thought it quite exciting to even include Atlantic Standard Time, as 
well as the zones for Hawaii and Alaska, although getting the latter 
turned into a bit of an exercise.

I was working at The Rand Corporation at the time and had been told that 
the Librarian there had magical research skills.  The timezone topic 
finally prompted my contacting her and asking for help.  She said she'd 
see what she could find.

I don't think it was as much as a half-hour before she called back with 
the answer.  I was duly impressed.  (Astonished would be the more apt 
word.)  So I asked her how she found the answer that quickly.

She told me she call the phone company's information operator for Juneau 
and asked her what they called their timezone. She then repeated the 
exercise for Oahu...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 14 Apr 2021 09:00:55 +0000

I would say for this particular example of security logs you should use ISO8601 (aka RFC3339), as it is more important when it happened/expires internationally rather than what timezone it happened in. 

In that case it should also be UTC-based or have an explicit timezone, e.g. considering "Zero day" - which day?

As a side effect  dates are also nicely sortable!

-- 
Stian Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note that I may work flexibly – whilst it suits me to email now, 
    I do not expect a response or action outside of your own working hours.

On 2021-04-14, 05:23, "art on behalf of Dave Crocker" <[email-masked] on behalf of [email-masked]> wrote:

    d/

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Apr 2021 10:21:25 +0000

Dave Crocker <[email-masked]> writes:

>I was working at The Rand Corporation at the time and had been told that the
>Librarian there had magical research skills.

Ook!

Peter.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Apr 2021 07:16:48 -0400

> In that case it should also be UTC-based or have an explicit timezone, e.g. considering "Zero day" - which day?

  Add to that the problem that time zones change over time.  That information can be lost, or unknown to later consumers of the data.

  What we've learned in the AAA environment (ISP / Telco) is that there are two reasonable choices for dates:

1) whatever you use locally, because it will never go off-system, and no one else will ever see it

2) RFC 3339

  Alan DeKok.

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Apr 2021 15:29:17 +0100

> this draft is intended to be human readable, and so 5322 doesn’t seem

security.txt is also likely to be written by humans, and RFC 5322 dates
have a lot of subtle details that are difficult to get right. For
instance, what is a parser supposed to do if the day of week is
inconsistent with the date?

RFC 3339 is much simpler to write by hand.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Slight or
moderate. Showers. Good.

---

From: heather flanagan <[email-masked]>
Date: Wed, 14 Apr 2021 07:52:31 -0700

> Just my opinion, of course.

I’m going to +1 John’s advice as well,  and suggest that if/when this group comes to a consensus on the topic, ask the RFC Editor to consider including the guidance in the style guide.

Heather

---

From: tom petch <[email-masked]>
Date: Wed, 14 Apr 2021 16:14:26 +0000

From: art <[email-masked]> on behalf of heather flanagan <[email-masked]>
Sent: 14 April 2021 15:52

<tp>
which I note is not the format that we are allowed to use in an RFC when it comes to references:-(

Tom Petch

Heather

---

From: Steve Allen <[email-masked]>
Date: Wed, 14 Apr 2021 09:18:08 -0700

> 1) whatever you use locally, because it will never go off-system, and no one else will ever see it

I offer that every datetime should be ISO 8601-like except in cases
where bureaucratic requirements demand something different.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: heather flanagan <[email-masked]>
Date: Wed, 14 Apr 2021 10:05:07 -0700

> which I note is not the format that we are allowed to use in an RFC when it comes to references:-(

Ah, yes, the format of bibliographic references is its own special beastie. That’s driven by the Chicago Manual of Style format. I’d suggest letting that particular sleeping dog alone, and focus on what should be standard in the body of the document for the material targeted to humans. If you really want another thing to poke at, complete the discussion with consensus on what should be standard for machine-readable (I honestly don’t know if there’s already consensus on that or not).

Heather

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Apr 2021 15:36:50 -0400

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Apr 2021 16:54:57 -0700

> to keep security.txt up to date.

Yes, that.
We got a lot of LC feedback that (okay, I might be exaggerating for effect)
the future Internet would be littered with piles of stale security.txt
files to the extent that the mechanism would be rendered useless due to the
expectation of stale content.  Adding "Expires" serves as something of a
"dead-man's switch" that lets stale content age out relatively gracefully.

> 8601 is still easier to read than RFC 5322 time, especially for

And I think the authors have a clear answer for what to do here.

Thanks to everyone for the feedback.

-Ben

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Thu, 15 Apr 2021 10:30:03 +0000

On 2021-04-14 Phillip Hallam-Baker <[email-masked]> wrote:

> 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.

Leap seconds won't go away unless you change the duration of a second or planet's rotation..

I don’t think UTC or TAI makes a big difference in this draft on security!  But it can make a big difference if assuming 00:00:00 UTC as it can become 23:59:59 (or indeed 23:59:60) on the previous day.

Here's my little developer hint if dealing with dates in unknown timezones and unknown time, needing to be transformed to timestamps for calculations/comparisons:

Assume 10:00 UTC, and then it will at least be the same date in almost all timezones and daylight savings through the year. 

Perhaps to avoid TAI problem we can add 15 minutes to 10:15 UTC, e.g https://everytimezone.com/s/e0c43e02

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Apr 2021 09:14:05 -0400

> Leap seconds won't go away unless you change the duration of a second or

Untrue, there is no reason that time needs to bear any relation to the
rotation of Earth, Saturn or any other planet. The time of noon changes by
15 minutes over the course of a year in Northern Europe.

Why not move the longitude lines to compensate instead?

> I don’t think UTC or TAI makes a big difference in this draft on
> security!  But it can make a big difference if assuming 00:00:00 UTC as it
> can become 23:59:59 (or indeed 23:59:60) on the previous day.
>

That is only one means of adjusting for leap seconds. Most infrastructure
has moved to smearing the second in over a longer time to avoid
instability. The people who maintain the parts of various platforms dealing
with time know all about leap seconds. But none of the ones I use generate
23:59:60 because the risk of breaking things with an untested, untestable
code path is simply too great to be worth doing.

And that is the root of the problem, there is no consistency across
platforms and applications in applying leap seconds. It is impossible to
know whether you are dealing with adjusted or unadjusted time.

---

From: Henry Story <[email-masked]>
Date: Thu, 15 Apr 2021 15:29:34 +0200

What about unix time: seconds or milliseconds since the Unix Epoch?
That removes all kinds of parsing problems as well as calendaring problems.
And it fits well with RFC8941 Structured Fields SfInteger.
That is used by Signing HTTP Messages draft in their Signature-Input header.

> On 13. Apr 2021, at 20:43, Yakov Shafranovich <[email-masked]> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 15 Apr 2021 13:36:18 +0000

>What about unix time: seconds or milliseconds since the Unix Epoch?

If you're going to use epoch-based stuff then go with Julian dates, which is a
well-established way of fixing moments in time with arbitrary levels of
precision.  It's currently 2459320.0656944.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 15 Apr 2021 14:21:04 +0000

Perhaps asking the NTP folks for views?

---

From: Tony Finch <[email-masked]>
Date: Thu, 15 Apr 2021 15:36:08 +0100

> What about unix time: seconds or milliseconds since the Unix Epoch?

Not human-readable or writable.

It's very easy to turn an RFC 3339 date-time into POSIX time.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Rattray Head to Berwick upon Tweed: Southerly or southeasterly 3 or 4,
occasionally variable 2 in south, increasing 5 at times later in far
north. Smooth or slight. Fair. Good.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Apr 2021 16:51:32 +0200

> Perhaps asking the NTP folks for views?

Not needed.

We are talking about security.txt, and the question was whether this text-based format should use RFC 3339 or RFC 5322.  The answer is that the latter is a legacy format with a ton of problems, and RFC 3339 (preferably simply with UTC time) is the answer.

There are great applications for POSIX times (NTP, RFC 8949 tag 0/1), MJDs (RFC 8943), etc., but all this is not needed for the bog-standard date/times needed for security.txt.  Leap seconds are irrelevant for this, as are Julian Dates, and probably even time zones (if we assume a minimum level of skill on the side of the people creating security.txt files).

Grüße, Carsten

---

From: Steve Allen <[email-masked]>
Date: Thu, 15 Apr 2021 08:53:47 -0700

> 15 minutes over the course of a year in Northern Europe.

Ramadan Mubarak!  Note that the reason that leap seconds were not
abandoned at the 2015 ITU-R WRC is that 6 nations whose national
holidays are based on direct observation of celestial events objected.
International legal issues are why leap seconds were created in 1970.
This thread needs to leave here now and move to someplace like the
Leap Seconds Discussion List.
https://pairlist6.pair.net/mailman/listinfo/leapsecs

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Apr 2021 15:31:23 -0400

On Thu, Apr 15, 2021 at 11:53 AM Steve Allen <[email-masked]> wrote:

> abandoned at the 2015 ITU-R WRC is that

Is actually that nobody threatened to take away the toys from the
astronomers.

Big Tech is more than big enough to end UTC, all it takes is the willpower
to move to a different scale.

> 6 nations whose national

If their holidays are based on observing celestial bodies, they should be
observing said bodies and UTC is precisely irrelevant.

> International legal issues are why leap seconds were created in 1970.

Yet more of your vague, unspecified 'reasons'.

The real reason is a bunch of astronomers get a feeling of importance from
coming down from the mountain and telling everyone to snap their heels at
their direction.

> https://pairlist6.pair.net/mailman/listinfo/leapsecs

Not a list where the decision makers are.

---

From: "Mark Baushke (ietf)" <[email-masked]>
Date: Wed, 14 Apr 2021 13:53:46 -0700

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> <elear=[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Apr 2021 02:29:35 +0200

> (I do not see a need to consider femto, atto, zepto, or yacto seconds at the present time.)

I don’t know why this discussion is continuing on the SAAG list, but let me add one factoid anyway:

The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond resolution [1] because the Haskell date/time libraries need that (which in turn probably just try to be one step ahead of UNIX nanosecond resolution).  (The CBOR tag also has femtosecond and attosecond resolution, because these are still cheap with 64-bit integers.  Zeptoseconds, yoctoseconds, and anything else down to and beyond Planck units can be added later based on bignums.)

A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~ 0.3 mm (~   12 thou), which is well beyond the tolerances to which e.g. connectors can be manufactured, so while these are not easy to achieve as date-time precisions, as durations (time differences) they are in wide use (as are femtoseconds and even attoseconds).

RFC 3339 has no problem with decimal fractions at all, so there is no need for invention as long as we talk about text strings for date-times.

Grüße, Carsten

[1]: https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#name-keys-3-6-9-12-15-18

---

From: Metapolymath Majordomo <[email-masked]>
Date: Sat, 17 Apr 2021 20:32:21 -0500

Hi Yakov,

I'm inclined to agree with Carsten.
RFC 3339 section 5 seems to cover the general guide and recommends use of
ISO 8601 for internet protocols. To the point on fractions of a second with
RFC 3339 § 5.3 Rarely Used Options.

Then my current understanding when a rarely used option is needed for
communicating an information interchange that needs such precision the use
of
ISO 8601-1:2019 and ISO 8601-2:2019 contain the guidance for what should be
used.

That being noted, was there something of security interest that is not
fully covered by RFC 3339, ISO 8601-1:2019 and ISO 8601-2:2019 or a
proposed RFC for SAAG that is not covered by these standards that we can
look at specifically that you're concerned about? If so, please provide
your specific concerns.

With Regard,

Kronah Wood
Metapolymath, LLC
PO Box 19236
Lenexa, KS 66219-9236
+1.2139158297

Sent from Mobile

On Sat, Apr 17, 2021, 7:30 PM Carsten Bormann <[email-masked]> wrote:

> > 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.
> The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond
> resolution [1] because the Haskell date/time libraries need that (which in
> turn probably just try to be one step ahead of UNIX nanosecond
> resolution).  (The CBOR tag also has femtosecond and attosecond resolution,
> because these are still cheap with 64-bit integers.  Zeptoseconds,
> yoctoseconds, and anything else down to and beyond Planck units can be
> added later based on bignums.)
>
> A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~
> 0.3 mm (~   12 thou), which is well beyond the tolerances to which e.g.
> connectors can be manufactured, so while these are not easy to achieve as
> date-time precisions, as durations (time differences) they are in wide use
> (as are femtoseconds and even attoseconds).
>
> RFC 3339 has no problem with decimal fractions at all, so there is no need
> for invention as long as we talk about text strings for date-times.
>
> Grüße, Carsten
>
> [1]:
> https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#name-keys-3-6-9-12-15-18
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 17 Apr 2021 21:36:43 -0400

I think the consensus is clear - to use ISO 8601 / RFC 3339. Thank you all!

On Sat, Apr 17, 2021 at 9:32 PM Metapolymath Majordomo
<[email-masked]> wrote:
> RFC 3339 section 5 seems to cover the general guide and recommends use of ISO 8601 for internet protocols. To the point on fractions of a second with RFC 3339 § 5.3 Rarely Used Options.
>
> Then my current understanding when a rarely used option is needed for communicating an information interchange that needs such precision the use of
> ISO 8601-1:2019 and ISO 8601-2:2019 contain the guidance for what should be used.
>
> That being noted, was there something of security interest that is not fully covered by RFC 3339, ISO 8601-1:2019 and ISO 8601-2:2019 or a proposed RFC for SAAG that is not covered by these standards that we can look at specifically that you're concerned about? If so, please provide your specific concerns.
>
>
>
> With Regard,
>
> Kronah Wood
> Metapolymath, LLC
> PO Box 19236
> Lenexa, KS 66219-9236
> +1.2139158297
>
> Sent from Mobile
>
>
>
>
>
>