Timezone may have side-effects

• Key: LOGCXX-11
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Curt Arnold
• Reporter: Curt Arnold
• Component/s: Layout
• Affects Version/s: 0.9.7
• Fix Version/s: 0.10.0

Description

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=[e-mail]&msgNo=247

I had been troubled by timezone.cpp, but have not had time to
investigate the issue. It appears that it could have unintended side
effects since it appears to be setting the current timezone not just
for the logging code but for the application as a whole.

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=[e-mail]&msgNo=121

Reported some confusion on the use of timezone in configuration files.

I would appreciate any suggestions on formatting date/times for non-default timezones. May check the GNU class library implementation of Time etc to see how they did it.

Comments

[Curt Arnold]

Additional reports:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=[e-mail]&msgNo=252

From: Paul Nader <[e-mail]>
Subject: Bug in RollingCalendar?
Date: Wed, 1 Sep 2004 19:09:59 +0200
Content-Type: text/plain;
        charset="us-ascii"


Hi,

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?


---------------------

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=[e-mail]&msgNo=376


Subject: Log4cxx obliterates the TZ setting...
From: [e-mail] <[e-mail]>
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

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?

[Curt Arnold]

Timezone has been reworked to work on APR time methods and no longer manipulate the TZ environment variables. GMT, fixed offsets from GMT and locale time are currently supported. Arbitrary timezones (America/Chicago for example) are not supported and would require ICU4C and/or platform specific code.