On Fri, 20 Sep 2013, Rainer Gerhards wrote:
Hi all,
maybe someone over here has an idea ;)
As you've probably seen that I have added a parameter "defaultTZ" to imtcp
(experimentally, to get started). The core idea is to set a TZ for those
devices that do not provide it. As usual, there are subtle issues. Ideally,
I'd like to set it to something like "ET", which means I would somehow need
to obtain DST change information.
Does anyone have an idea of how this could be done without considerable
effort (like re-implementing DST parameters). I know that even then there
are multiple subtle issues lurking, but I think a basic, "works mostly
right" version would be useful...
All Linux APIs I have researched so far rely just on the local system
timezone. All proposed methods to do conversions I have found so far rely
on modifying the TZ envvar, which does not really work for a multithreaded
app like rsyslog (except if I make conversion extremely costly) and also
cost quite a bit of performance.
Have I overlooked some simple approach?
no, this is a gap on linux systems.
the 'right' answer is for glibc to split it's time handling routines that
currently convert localtime <-> gmt into two functions, the first extracts the
TZ from the environment, the second does the conversion with the TZ explicitly
passed to it (called from the existing routine that just retains the first part
in it's code)
but it seems like this is something that people have been asking for for many
years, so it's probably not going to happen :-(
the easiest thing to do would probably be to find an apache/bsd licensed libc
and copy the timezone conversion routines from it, but modify them to allow you
to explicitly pass the 'local' timezone rather than reading it from the
environment. Doing this would have the advantage that it would use the existing
system timezone database, so you wouldn't have to re-write all of that handling.
I really don't like the idea of doing a new conversion routine from scratch,
it's going to end up needing to gain just about all the functionality of the
libc ones eventually, and it will be an ongoing source of bugs if you recreate
it rather than finding something that's license compatible that you can copy.
The good news should be that the libc code should be very stable, something that
has not changed in many years, so all the bugs are worked out of it :-)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
