On Sat, Jul 19, 2014 at 4:26 PM, Rainer Gerhards <[email protected]> wrote:
> On Sat, Jul 19, 2014 at 3:19 PM, Rainer Gerhards <[email protected] > > > wrote: > > > > > On Fri, Jul 18, 2014 at 8:54 PM, Radu Gheorghe < > [email protected] > > > wrote: > > > >> Thanks, Rainer! I didn't know of the timezone object. > >> > >> > > It's new, I think I implemented it monday ;) > > > > > >> Is there a way one could use it to convert a timestamp to UTC? And this > >> resolve Eugene's initial problem? > >> > >> > > no. It's just like the doc says: its a helper for parsers, so that they > > know TZ offsets when a TZ string is given. Of course, it could be > extended, > > but it's a bit tricky with the bad state of Linux TZ information. In > > essence, one needs to duplicate what the system provides in a way that's > > unusable for multithreaded apps (there were a couple of mailing list > > discussions on this topic, you also find it on the Internet. In a > notshell, > > all TZ API calls rely on the TZ environment variable which is slow and > > problematic). > > > > > well, thinking a bit more about it. What one could do is > > 1) convert given timestamp to time_t > 2) apply offset info to it, so we now hat a time_t in actual UTC > 3) convert it back to a syslog date, which then also is UTC > > someone up for a patch? > I would do it, but I don't have the skills yet. I'm up for testing the patch, though, if that helps. Best regards, Radu _______________________________________________ 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.
