Re: [calsify] Fwd: New Timestamp Draft

[Ned Freed <[e-mail]>]

> 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