From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4539 Path: news.gmane.org!not-for-mail From: Paul Schutte Newsgroups: gmane.linux.lib.musl.general Subject: Re: syslog() always sends GMT timestamps Date: Sat, 1 Feb 2014 19:07:42 +0200 Message-ID: References: <500a674a-fd43-49f5-99b8-6fd0b18ef5a2@email.android.com> <20140128171153.GL24286@brightrain.aerifal.cx> <770108a1-99d7-4ef0-b860-b045866c9895@email.android.com> <20140130043344.GR24286@brightrain.aerifal.cx> <20140130120413.GT1685@port70.net> <20140201005419.GZ24286@brightrain.aerifal.cx> <52EC4D3F.8090403@skarnet.org> <20140201090914.GW1685@port70.net> <52ED1768.2080809@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11336044216cac04f15b54b7 X-Trace: ger.gmane.org 1391274468 3256 80.91.229.3 (1 Feb 2014 17:07:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Feb 2014 17:07:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4543-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 01 18:07:56 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1W9e2t-0006aQ-0H for gllmg-musl@plane.gmane.org; Sat, 01 Feb 2014 18:07:55 +0100 Original-Received: (qmail 21829 invoked by uid 550); 1 Feb 2014 17:07:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21821 invoked from network); 1 Feb 2014 17:07:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qam8K538QTNtlwzrq9aGYvuegPbT7u7KVE1797UljKI=; b=GaL8G2g77PdtH61/9cgL36MbJ2/0KF4GHATdVsNvt3kjtUP50Jas0xwQs8ICBjPcU0 M7309izvtA+187ABKTj6M9HHCO6muENRSEoSC5hTFnTCVUaZSJnxw6cf33/ko2uI/8Em yyLCetw23ZIW8AolV3KhNlQCQr7bD+6YkXKyKuQMbnqHr4eWEMfU8ha1TxpbrlFUErKH iwf6OiTTFJiIQWgTY+nFg1Evg5ajGn/6SLbtPGHw0p1EtChhlDA72vudmgabhpEZyWBC 0isVgLE8EnSubPdoS3F/sLoR8hCd9NWpBFXpY0iD03b4Ga7jO8BlOwC/Kcyl9xvahW2R EhFQ== X-Received: by 10.152.219.37 with SMTP id pl5mr2192252lac.36.1391274462636; Sat, 01 Feb 2014 09:07:42 -0800 (PST) In-Reply-To: <52ED1768.2080809@skarnet.org> Xref: news.gmane.org gmane.linux.lib.musl.general:4539 Archived-At: --001a11336044216cac04f15b54b7 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --001a11336044216cac04f15b54b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have to chime in here.
=
The venerable squid proxy has generated logs with unix epoc times= tamps 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 hu= man consumption as mentioned. On the other hand if the log was in some huma= n readable form one has to start to dabble with inefficient things like Tim= e::ParseDate in perl to make computers understand it. Not to mention the ti= me zone mess.

Just my 2 cents.

Regards
Paul


On Sat, Feb 1, 20= 14 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)

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

=A0Historically, 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.

=A0So 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.

=A0And people can even read the raw files too, they just have to
run "s6-tai64nlocal < logfile | less" instead of "less lo= gfile",
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.)

=A0So, 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 !

--
=A0Laurent


--001a11336044216cac04f15b54b7--