Hi,
Strange indeed. To solve this the logging application and syslog-ng needs to agree on the time-zone being used.
syslog-ng uses the system time-zone by default but it can be overridden using the time-zone() option of the unix-dgram() source driver.
The applications should also use the system time-zone. Here it's usually the libc (glibc or musl) that generates the timestamp. More specifically the syslog() function. It might happen that:
* Some applications bypass the libc api and send its messages directly (util-linux logger does this for instance)
* If an application has its own implementation, it may or may not use the system time-zone properly.
To debug the problem, try to get access to the raw log data as received by syslog-ng.
* It displays the incoming message on the debug level
* You could strace the sending app
* You could tell syslog-ng to store $RAWMSG using flags(store-raw-message) and then look at its value by using a destination that you use for debugging.
In any case, once you recognize what sends the incorrect time-zone, you can probably find a reason why it sends it incorrectly.
If you just want to solve this quickly, use keep-timestamp(no), that way syslog-ng will overwrite the message timestamp with the reception time, and that with correct time-zone.
As a second alternative, you could use the pretty recent flags(guess-timezone) flag which uses a heuristic to fix up the time-zone, assuming the time between sending and receiving the message is less than 30 seconds.
Bazsi