Curt:
Added the changes to do this... (save/restore the TZ back)... HOWEVER... I'm seeing that there is some sort of static initialization that's resetting the TZ?
The following two files have my save & restore code added around the tzset().... these files have the tcout being used to display when I save / restore them... they should be commented out I guess...
However, I still see the following when executing my code. Notice how it goes from US/Eastern to '' ... and then to US/Eastern... and then to GMT... and the "SmartACD.cpp:174" is the first print statement from MY code.. so I assume a static initializer or two is being kicked in... but where?? I don't use any static log4cxx stuff...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TimeZone::TimeZone() - Old timezone being saved as 'US/Eastern' and setting to 'TZ=GMT'
TimeZone::TimeZone() - Restored timezone to TZ=US/Eastern
TimeZone::TimeZone() - Old timezone being saved as '' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=
SmartACD.cpp:174 -> TZ = 'US/Eastern' -> TZName[0] = 'EST', TZName[1] = 'EDT'
SmartACD.cpp:181 -> TZ = 'US/Eastern' -> TZName[0] = 'EST', TZName[1] = 'EDT'
TimeZone::TimeZone() - Old timezone being saved as 'US/Eastern' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=US/Eastern
TimeZone::TimeZone() - Old timezone being saved as 'GMT' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=GMT
Could not connect to remote log4cxx server at [ultra60]. We will try again later.
Connection refused
TimeZone::TimeZone() - Old timezone being saved as '' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=
Could not find value for key log4j.appender.sapp2
Could not instantiate appender named "sapp2".
SmartACD.cpp:191 -> TZ = 'GMT' -> TZName[0] = 'GMT', TZName[1] = ' '
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My source code that created the above log entries...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int main(int argc, char *argv[])
{
putenv("TZ=US/Eastern");
printf("%s:%d -> TZ = '%s' -> TZName[0] = '%s', TZName[1] = '%s'\n",
__FILE__, __LINE__,
getenv("TZ") ? getenv("TZ") : "<>",
tzname[0], tzname[1]);
openlog("SmartACD", LOG_PID, LOG_USER);
printf("%s:%d -> TZ = '%s' -> TZName[0] = '%s', TZName[1] = '%s'\n",
__FILE__, __LINE__,
getenv("TZ") ? getenv("TZ") : "<>",
tzname[0], tzname[1]);
sigset(SIGHUP,sig_hdlr);
sigset(SIGUSR2,sig_hdlr);
log4cxx::PropertyConfigurator::configureAndWatch("SmartACD.ini");
printf("%s:%d -> TZ = '%s' -> TZName[0] = '%s', TZName[1] = '%s'\n",
__FILE__, __LINE__,
getenv("TZ") ? getenv("TZ") : "<>",
tzname[0], tzname[1]);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Renny Koshy
President & CEO
--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com
|
|
Curt Arnold <carnold <at> apache.org>
09/01/2004 01:56 PM
Please respond to "Log4CXX User"
|
To: Log4CXX User <log4cxx-user <at> logging.apache.org>
cc:
Subject: Re: Log4cxx obliterates the TZ setting... |
I had noticed the potential for the problem and logged it as
http://nagoya.apache.org/jira/browse/LOGCXX-11. Thanks for confirming
that is actually a problem. My suspicion is that gmtime or gmtime_r is
not adequate since log4cxx may need to format times to a time-zone
other than the current time zone. However, it might be an optimization
if the timezone for the layout and the current timezone are the same.
I guess the first thing is to at least reset the value of TZ to the
initial value after collecting time zone offsets.
On Sep 1, 2004, at 11:40 AM, renny.koshy <at> rubixinfotech.com wrote:
>
> 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
>
> Questions:
> 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?
RSS Feed