Re: [calsify] Fwd: New Timestamp Draft

[Ned Freed <[e-mail]>]

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