Re: [calsify] Fwd: New Timestamp Draft

[Shane Carr <[e-mail]>]

A few things:

- 3339 and 8601-1 are good as a timestamp format.  The extension Ujjwal
proposed generalizes those formats based on the demonstrated needs of the
ecosystem when dealing with "human dates" as opposed to "computer dates".
It's an interesting observation that timestamps (e.g. log files) are
typically used for contemporary events, so the extended 6-digit year format
may not really be necessary.  Therefore, I think it would be a reasonable
option to keep 3339 unmodified and alive as the timestamp format, and
consider the new proposal to be a peer.

- I see a thread with Eliot Lear, but I don't see where the pros and cons
of a combined RFC versus separate RFCs are discussed.  (But this is moot if
we were to decide to keep RFC 3339 alive in its current state.)

- The key question solved by this RFC is the data model.  What Ujjwal is
proposing is to use a timestamp paired with information about the time zone
and calendar system.  Once we agree on the data model (I do), then we can
talk about how to package the data.  Could we use JSON?  Sure, but we still
need to specify the structure of the JSON and what form the keys/values can
take.  Ujjwal is proposing a string syntax with bracketed annotations
because (a) it is already used in the wild, and (b) compared with JSON,
strings are more compact [no keys], more compatible [byte array rather than
struct/map], and easier to deal with [no need to format/stringify].  I hope
not to get into a debate on point (b), but if there are people here who
believe that we should stop defining new string syntaxes and instead let
JSON (ECMA-404) rule all, then we may need to engage on that topic.

Shane


On Sun, Jan 24, 2021 at 10:22 PM Ned Freed <[e-mail]> wrote:

> > I think the disagreement here stems from two viewpoints on what RFC3339
> is.
> > Ned is looking at it from the viewpoint that it defines a format for
> (log)
> > timestamps only.
>
> Not quite. I pointed out that RFC 3339 was and is used for timestamps in
> logs.
> I never said, or even implied, that it doesn't have (many) other uses,
> either
> by itself or in combination with other information.
>
> However, the more important point, as you note below, is that RFC 3339
> specifies a timestamp format. It's entirely self-contained, and aside from
> allowing specification of a time zone offset, it provides no information
> about
> presentation or anything else.
>
> > The other side is viewing it as simply a standard serialisation format
> for
> > dates in internet protocols without restriction on use case.
>
> That may be true but I question the relevance. There are a myriad of use
> cases
> for RFC 3339. There are also a myriad of use cases for RFC 3339 combined
> with
> other information. I don't think anyone is claiming otherwise.
>
> The issue here isn't that these other cases aren't worthy of consideration
> -
> they are - it's that addressing them by changing the core semantics of a
> widely
> used timestamp format isn't the right way to go about it.
>
> > Having looked at the document's introduction again, Ned is technically
> > correct:
>
> >    There are many ways in which date and time values might appear in
> >    Internet protocols:  this document focuses on just one common usage,
> >    viz. timestamps for Internet protocol events
>
> Exactly.
>
> > However, I would assert that in my experience, many view RFC3339 as just
> a
> > standardised serialisation format for all dates in contexts that go
> beyond
> > this.
>
> I don't know what this means. RFC 3339's semantics are clear, and the
> syntax
> only allows for the expression of those semantics. If you "go beyond" those
> semantics, you either have to extend the syntax, in which case you're not
> talking about RFC 3339 format any more, or you have to create some sort of
> grouping of RFC 3339 with additional information. In either case you have
> extended RFC 339, and that's not a matter of how you view it.
>
> > I think there is a clear demand for a serialisation format that *can*
> > incorporate a time zone or calendar identifier, and standardising this
> within
> > the IETF is more likely to lead to interoperability. I also agree that
> you
> > would never want to use such a time-zone variant in log files.
>
> OK... so it sounds to me like we're in agreement that RFC 3339's
> semantics need to be retained. Good.
>
> > So I think it comes down to two options:
>
> >  * A single RFC that replaces 3339 containing all the variants. The
> benefit
> >    is you have one place to reference for how to serialise a date-time.
>
> Eliot already explained why this is a really bad idea.
>
> >  * A new adjunct RFC for how to serialise date-times with IANA time
> zones, or
> >    without an absolute time at all (local "wall clock" date-times).
>
> A convention for this is already provided by RFC 3339, actually. Section
> 4.2.
>
> >    This
> >    would not overlap 3339, which would continue to define how to
> serialise
> >    UTC and fixed-offset date-times.
>
> This is a little confusing: Adjunct implies that you're extending RFC
> 3339, "no
> overlap" implies you're not. In any case, I would recommend building on the
> existing syntax of RFC 3339 if possible.
>
> > I am not too fussed which of these paths we go down.  I was originally
> > advocating for the first option, but looking at it again, I can see good
> > arguments for the second instead.
>
> Exactly.
>
>                                 Ned
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>