Re: [calsify] Fwd: New Timestamp Draft

[Ned Freed <[e-mail]>]

> 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