Re: [calsify] Fwd: New Timestamp Draft

[Bron Gondwana <[e-mail]>]

ISO8601 had a major update in 2019, due to there being demand to be able to represent additional types of date information.

But this does sound like everyone would be a lot happier with a small update to 3339 to remove 2 digit years, allow 6 digits years, and otherwise leave pretty well enough alone - and then define a new format for everything else.  I expect that would be acceptable.

Cheers,

Bron.

On Mon, Jan 25, 2021, at 00:55, Ned Freed wrote:
> Of course the other way to solve all of these problems is to leave RFC 3339 and
> ISO 8601 alone, and instead specify a new format that incorporates RFC 3339  as
> a component, the same way you're incorporating time zone rule names, calendar
> names, and on.
> 
> Then implementors can choose on a case by case basis which format best
> meets their needs.
> 
> Almost all of the issues here revolve around the fact that you're updating
> an existing format.
> 
> Ned
> 
> 
> 
> 
> > > Ned,
> 
> > > Would your concern here be resolved by having this draft define a "point in
> > > time" profile which was RFC3339 minus the 2-digit-year option, and a "full
> > > date" profile which includes all the rest of the details - such that logging
> > > software could be defined to use the "point in time" profile.
> 
> > Maybe. I don't have any objection to deprecating features of RFC 3339 that
> > experience has shown we don't want or need.
> 
> > However, I don't think you've really made the case that the full date stuff is
> > best addressed by packing all kinds of stuff in a single field value. It's not
> > like JSON, XML, and so on have no mechanism for specifying a group of related
> > values. As such, I question the need to define an additional syntax to do this,
> > one that's considerably less flexible.
> 
> > There's also the issue of what constraints are applied to the additional stuff.
> > The obvious one is that it MUST NOT be allowed to move the point in time
> > of the timestamp around - I don't see this stated anywhere.
> 
> > > I'm really keen for there to be an RFC which can be referenced by both new
> > > calendaring drafts and by other IETF documents, which is developed by this
> > > group of people who are already involved in both the ISO work (via Ronald and
> > > CalConnect) and the ECMA standardisation effort.
> 
> > > Generality has real costs, but so does excess simplicity - if there's not a
> > > standard way to describe things that people really need, then they all develop
> > > their own extensions.
> 
> > Actualy, it's this draft that engages in excess simplicity - the simplicity,
> > for example, of assuming that it never makes sense to associate more than
> > one set of time zone rules with a timestamp.
> 
> > And there's no missing standard here. We have no shortage of standardized
> > grouping syntaxes.
> 
> > > This effort is to capture the extensions that have been needed in the real
> > > world already, and standardise them to encourage everyone to extend the same
> > > way!
> 
> > I'm a very long way from being convinced of this.
> 
> > Ned
> 
> > > Cheers,
> 
> > > Bron.
> 
> > > On Sun, Jan 24, 2021, at 11:00, Ned Freed wrote:
> > > >
> > > > > On 1/23/21 18:17, Ned Freed wrote:
> > > > > > Generality has real costs. To name the obvious example, I don't want to
> > > > > > *ever* see a timezone rule in a log file timestamp, or a field in an
> > > > > > email message.
> > > >
> > > > > I have had a number of conversations with people tasked with auditing
> > > > > log records bemoaning the lack of a timezone id in logs. Without the id
> > > > > how do we know how an offset or UTC date was calculated?
> > > >
> > > > The purpose of a time value in the sorts of logs I'm talking about is to
> > > > accurately describe the moment in time when something happened. Nothing more,
> > > > nothing less. The RFC 3339/ISO 8601 format gives you this along with the
> > > > ability to specify the value as an offset from GMT.
> > > >
> > > > If you really want more information along the lines of what this draft
> > > > provides, like what timezone rules were in effect somewhere or what calendar it
> > > > should be "projected to" (to use the draft's terminology), then by all
> > > > means include that in a separate field in the log.
> > > >
> > > > With computers increasingly going back to being shared resources in some random
> > > > data center some place other than anyone involved in generating the log entry,
> > > > figuring out the right "somewhere" is a highly nontrivial problem. This
> > > > is  true even for time zone offsets, and the further you go the harder it gets.
> > > > (Of course this doesn't stop people from using offsets in their logs even when
> > > > they have nothing to do with anything other than the location of some random
> > > > piece of hardware.)
> > > >
> > > > And of course there can be multiple somewheres, which means these values need
> > > > to have additional semantics attached in order to be interpreted properly.
> > > >
> > > > All of which argues strongly for not combining what are in fact separate
> > > > pieces of information.
> > > >
> > > > Given all this, my advice to your auditor pals is, "Be careful what you wish
> > > > for, because you're likely to end up with useless garbage."
> > > >
> > > > There's also very strong trend in the logging world to try and avoid complex
> > > > field values because they hugely complicate aggregation, searching and sorting
> > > > operations. In this world the use of RFC 3339 may be profiled to GMT only, or
> > > > replaced entirely by a UNIX epoch or milliepoch values.
> > > >
> > > > > it's simply an offset showing what's considered to be local time.
> > > >
> > > > ? Offsets are a standard part of ISO 8601/RFC 3339.
> > > >
> > > > > Accurately recording the date/time that an event occurred is as
> > > > > important for logging as it is for future events.
> > > >
> > > > ?? None of this has anything to do with accuracy. If you're not putting
> > > > in the correct offset for your time values you're doing it wrong.
> > > >
> > > > > {and I don't think we're talking about rules - just ids]
> > > >
> > > > ??? We most certainly are talking about rules. If you think otherwise you
> > > > need to reread the draft.
> > > >
> > > > Ned
> > > >
> > > > _______________________________________________
> > > > calsify mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/calsify
> > > >
> 
> > > --
> > >   Bron Gondwana, CEO, Fastmail Pty Ltd
> > >   [e-mail]
> 
> 
> 
> > _______________________________________________
> > calsify mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/calsify
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]