From: Paul Nader <Paul.Nader@telefonica.net>
Subject: Bug in RollingCalendar?
Date: Wed, 1 Sep 2004 19:09:59 +0200
Can someone explain why does RollingCalendar::computeTriggeringPeriod
permanently overrides the user's TZ environment variable?
Shouldn't it fetch the users value with getenv, save it temporarily, then set TZ
to GMT and when it's finished restore it?
If this is not a bug, can someone explain what the intent is?
Subject: Log4cxx obliterates the TZ setting...
From: firstname.lastname@example.org <email@example.com>
Date: Wed, 1 Sep 2004 12:40:24 -0400
Content-Type: multipart/alternative; boundary="=alternative 005B972C85256F02="
We have some code which started behaving strange after going to log4cxx for logging... I've isolated it down to the fact that log4cxx obliterates the TZ settings in timezone.cpp and dailyrollingfileappender.cpp
Instead of changing to GMT to calculate the diff, why not use
gmtime() or gmtime_r()? I've done this in our code that had to calculate this difference for a LogFile class that dates back almost 8 years... - This way there is not "side-effect"...IF I change the code to work that way, any chance of having it included in the 'official' package?