svlogd localtime option

[Jared Rhine <jared@wordzoo.com>]

  Jared> Would there be resistance to having [svlogd] be really useful by
  Jared> supporting a -ttt which uses localtime? [...] I appreciate
  Jared> that UTC-based servers are useful...

  Gerrit> Using TAI or UTC has the great advantage that logs are
  Gerrit> sortable after merging, this is not guaranteed when using
  Gerrit> localtime.

As mentioned, I understand that UTC has advantages.  With mutual
respect as professionals, I disagree with that characterization of
"great advantage" though, especially in comparsion to the
disadvantages.  The disadvantages hit me every single day, whereas
I've never once wanted to do a simple log merge in 10 years across
dozens (hundreds?) of servers.  When I do, it's always script-mediated
and my localtime can easily be transformed back into UTC or TAI64n
specifically for that purpose (though that's not how I do it).

Why is UTC there at all?  TAI64n has some minor advantages over even
UTC, so why don't we force everyone to pipe everytime?  Presumably to
save some humans some time.

It simply seems wise to support the common use case, which is maybe
95% browsing, 4% archiving, and 1% merging.  Instead, I should need to
incorporate a pipeline for 99+% of the times I use the file, instead
of the <1% of the time I need to merge?  And cause extra work every
time I'm grepping, opening in an editor, etc.  Of course I can
construct command lines pipes and aliases to work around the problem.
I just don't see why I'm working around it all.

  Gerrit> I think it's better to let the pager used to display logs do
  Gerrit> such jobs.

Fair enough.  But reasonable people can disagree on methods and
practices, and not everyone uses a pager for browsing.  This one
single issue is the sole gripe about the functionality of runit.

It's trivial for me to substitute gmtime with localtime, and my latest
installs are working great like that.  But now I'm maintaining a fork,
which seems silly for such a small (and useful!) change.  But if such
an enhancement would be rejected on design grounds, it's important
enough for me to do so.  I'd rather put that time into a patch that
would be accepted; 

  Charlie> Ambiguous times in log files are not such a good idea.

I'm a big boy; I'd prefer the rope to hang myself.  I'm just asking
for a switch that's maybe a couple lines of code, not to bring down
the entire sysadmin community with my wicked ways :)

Anyway, that's my pitch.  I tried to state it as strongly as I
politely can.  Still your call on the design/patch acceptance issue of
course.

-- jared@wordzoo.com

War is God's way of teaching Americans geography. -Ambrose Bierce