I have to chime in here.

The venerable squid proxy has generated logs with unix epoc timestamps for ages and it never has stopped anyone from reading those.
I am all for the ISO date format, but it makes a lot of sense to have it in either TAI64N or epoch time.
It is trivial to filter those for human consumption as mentioned. On the other hand if the log was in some human readable form one has to start to dabble with inefficient things like Time::ParseDate in perl to make computers understand it. Not to mention the time zone mess.

Just my 2 cents.

Regards
Paul


On Sat, Feb 1, 2014 at 5:48 PM, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:
On 2014-02-01 01:09, Szabolcs Nagy wrote:

yes there is nothing clearer than a 24 digit hexadecimal number
representing time to the nanosecond

at least the last 3-4 digits in the log can be used as a random
sequence

(i've seen this in practice and have no idea how anybody could
ever think that it's a good idea.. must be some sysadmin logic
that is beyond the reach of average mortals)

 I was half-trolling, but since you bit the hook:

 Historically, logs were made to be read by human beings, so it
made sense to print timestamps in a human-readable format. But it
is less and less the case. Logs are getting more and more
automatically processed, filtered, aggregated, analyzed, which is
a good thing. Humans nowadays only look at raw textual log data once
everything else has failed, including visualizing them in some web
interface that also processes them for display.

 So it actually makes more sense to write logs in a format that is
easily parsable and usable by *computers*, and timestamps are a big
part of it. Human time is complex to understand for computers (and
even for humans not living in the same time zone). TAI64N is simple,
and makes processing easy as pie. (Mmmm... pie.) Merging log files
chronologically ? Just cat all your log files together, pipe them
through sort, done. Oh, and it works with log files from other
machines all around the world, without a concern for timezones or
human time quirks such as DST, too. Want to strip the timestamps
for some reason ? Pipe your logs through "cut -c27-", done.

 And people can even read the raw files too, they just have to
run "s6-tai64nlocal < logfile | less" instead of "less logfile",
which is the simplest processing you could think of - a UNIX filter.
(I've heard that Great Sysadmins can understand TAI64N directly in
the text, but I couldn't tell, I'm not yet part of the Circle.)

 So, dear initiate, now that you know the greatness of automated
processing and of Unix filters, and have shaken off the myth that
logs have to be read exactly as they were written, you have risen
above average mortals, and are now a Sysadmin. Congratulations and
welcome !

--
 Laurent