Re: [calsify] Fwd: New Timestamp Draft

[Neil Jenkins <[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. The other side is viewing it as simply a standard serialisation format for dates in internet protocols without restriction on use case.

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

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

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.
 * 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). This would not overlap 3339, which would continue to define how to serialise UTC and fixed-offset date-times.
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.

Neil.