Re: Is there interest in a more customizable timestamp?

[ On Monday, December 20, 2004 at 09:32:13 (-0500), Philip J. Hollenback wrote: ]
> Subject: Is there interest in a more customizable timestamp?
>
> If you set conserver to add a timestamp to each line of the log file,
> the output looks like this:
> 
> [Mon Dec 20 14:46:56 PST 2004] blah blah blah
> 
> Which is ok, but kind of verbose.  It would be nice if this was more
> customizable.

That looks an awful lot like the standard output of ctime(3), and no
doubt it is.

For any C or Unix program that's about the most standard format for an
ASCII timestamp that could ever be possible.

>  For example, we would like to see a more compact
> representation that worked more like syslog, i.e.:

Well, since log files (or snippets from them) can stick around for much
longer than you might imagine I would very strongly suggest that you do
not ever want to drop the full year from the timestamp.

I think the only other form of timestamp that would be reasonable would
be a proper, truly standard, ISO 8601 format timestamp, i.e. like this:

	YYYY-MM-DD HH:MM:SS

The most compact complete form allowed by ISO 8601, though the least
human friendly, is:

	YYYYMMDDTHHMMSS

(where the "T" is a literal "T" character in the ISO-8851 character set,
and the rest are replaced by the appropriate digits of course)

The times of course _should_ be given in UTC, and that _should_ be
specified in the timestamp by appending a capital letter "Z".  That way
they cannot be confused when DST changes get in the way, nor will they
be confused should a system be used by users who are not all in the same
timezone (which is very common these days, even for "conserver" users!).

However at minimum the ISO standard timezone offset specification should
be appended to avoid confusion (e.g. "+HH:MM" or "-HH:MM" , or just
"+HH" or "-HH")

So, for a complete example the time as I type this is:

	2004-12-20 14:51:41-05

or in UTC:

	2004-12-20 19:51:41Z

> So at this point we are thinking about extending the timestamp
> functionality with full strftime time specifications.

I think that would be a really bad thing to do.  K.I.S.S.

Pick a standard, be complete, and stick to it universally.

For what it's worth I think the ctime(3) output we now use is quite
sufficient.  These log entries don't need to be parsed and hopefully
they're already in the correct order, and human readabilty and avoidance
of confusion factors is parmount.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>