[syslog-ng] Timezone problem?!

[Balazs Scheidler]

On Thu, 2009-02-12 at 09:52 +0800, Charles Chan wrote:
> I use time_zone instead timezone,configuration like this 
> ===========================================================
> template apache_template { template("$DAY-$HOUR $S_DAY-$S_HOUR
> $R_DAY-$R_HOUR $MSGONLY\n"); template_escape(no); };
> destination us_int_apache
> { file("/disk2/apache_logs/$YEAR-$MONTH-$DAY/$HOST.apache.log"
> timezone("PST8PDT") template(apache_template)); };
> ============================================================
> service can start,but the problem still exists.
> the file is stored in the /disk2/apache_logs/2009-02-12
> generated log is:
> 11-17 11-17 11-17  222.69.201.23 - - - [11/Feb/2009:17:37:03 -0800]
> "GET /atmgateway.client.html ...................
> two date string still difference. I use syslog-ng 3.0.1 OSE version,is
> this OSE version problem?

The PE and OSE versions are the same in this regard. Apart from the
concrete differences listed on our website, I work hard to keep the two
versions in sync.

So let me try to understand your problem a bit deeper... Sorry for not
having done so previously. Sometimes I just reply without really
thinking through problems in the question. 

hmm.. as I see your problem seems to be that the name of the file and
the _content_ of the file contains a different timestamp. Right?

This is intentional.

When expanding the macros in the name of the files, syslog-ng _always_
uses the server-side, local timezone. The timezone used in the content
of the file can be controlled using the time_zone() option.

Currently there's no way to control the filename zone offset. The
reasoning behind that was that I already found the timezone related
configuration options too complex, and I didn't see the need so far.
I felt that agregating logs based on the _received timestamp_ is more
trustworthy (because clients are free to specify a timestamp they
feel-like), and that is in local timezone anyway. Also, noone else has
complained previously :)

That said, I'm willing to add another option to control the timezone
used when expanding the filename, if you really think that solves your
problem.


-- 
Bazsi