On Thu, 29 Jan 2015, Rainer Gerhards wrote:
David once suggested to copy that code and utilize it. While I agree that
it is a decent solution, I don't want to do that. Alone keeping up on
security I consider a nightmare.
The real solution would be to submit a patch that makes a decent API
available, but that would probably mean I would need to set of quite a bit
of time to read and understand that code. As the TZ conversion question
doesn't come up very often, I don't consider the functionality important
enough to warrant a very lengthy implementation.
The "right" answer is a change to libc
currently libc has (don't know exact name) convert_to_utc() and
convert_to_local() functions. The problem is that they figure out what the local
timezone is by looking at an environment variable.
This "should" be a simple change
pseudocode of existing routine
time convert_to_utc( time input) {
localtz = loockup_environ("TZ")
stuff to do the conversion
}
change this to
time convert_to_utc( time input) {
localtz = loockup_environ("TZ")
convert_to_utc2(input, localtz)
}
time convert_to_utc2( time input, *char localtz) {
stuff to do the conversion
}
and a similar refactoring to the convert_to_local() call
This would not duplicate code, and would expose a function that people have been
needing for decades.
but it will take someone willing to dig into the glibc code, possibly
refactoring it to make it clean enough to meet what I list above as the starting
condition, and the willingness to tackle the glibc patch submission process
(including the FSF copyright assignment process if that is still required)
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.
