Re: Log4cxx obliterates the TZ setting...

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@xxxxxxxxxx> 09/01/2004 01:56 PM Please respond to "Log4CXX User"

To:        Log4CXX User <log4cxx-user@xxxxxxxxxxxxxxxxxx>         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@xxxxxxxxxxxxxxxxx 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?

timezone.cpp
Description: Binary data

dailyrollingfileappender.cpp
Description: Binary data