Re: [calsify] Fwd: New Timestamp Draft

[Bron Gondwana <[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.

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

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]