Re: [calsify] Fwd: New Timestamp Draft

[Ned Freed <[e-mail]>]

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