svlogd timestamps in local timezone

svlogd timestamps in local timezone

[Abhas Abhinav]

Hi Everyone...

I've got a small query on svlogd.

When we use the '-t' switch with svlogd it puts in tai64n compatible
timestamps in all log messages. Similarly, '-tt' puts the timestampts in
human readable form.

The problem is that both these options put the timestamps in UTC. So, if
the system's timezone is configured as something else, then the
timestamps don't really make too much sense to the user.

Is there wa way to get time stamps in the local timezone? Or if the
timestamps are logged in the tai64n format, is there a tai64nlocal-like
utility that can convert them to something in the local timezone?

Any thing on this will be very helpful...

Regards,
Abhas.
-- 
Abhas Abhinav / i-take-charge at DeepRoot Linux
Getting gnu/Linux to work for you. Faster. Better. Today. Every way.

Re: svlogd timestamps in local timezone

[Jared Rhine]

Abhas Abhinav wrote:

> Is there wa way to get time stamps in the local timezone?

Check the archives (search localtime and gmtime) for discussion of
enhancement requests (I proposed -ttt for localtime logging).

There were serious concerns on this list about correctness and
correctness is important to runit design.  The idea wasn't rejected
outright, but there also was no clear message a patch would be accepted,
so I didn't spend time putting one together.  I do run a number of
production runit installations where I've s/gmtime/localtime/ in the
code (just one place in one file), and it works fine.

> Or if the
> timestamps are logged in the tai64n format, is there a tai64nlocal-like
> utility that can convert them to something in the local timezone?

This pipe-based approach was viewed as the more correct solution, though
it didn't seem that the functionality was fully available at the time.
I'm concerned about a few use cases where this is bad for usability;
given that I view logs all the time, I judged that forking my runit
installs from upstream because of this issuepoint was easier than the
way logs themselves are reviewed.