Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.7
    • Fix Version/s: 0.10.0
    • Component/s: Layout
    • Labels:
      None

      Description

      http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-user@logging.apache.org&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=log4cxx-user@logging.apache.org&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.

        Activity

        Curt Arnold created issue -
        Hide
        Curt Arnold added a comment -

        Additional reports:

        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-dev@logging.apache.org&msgNo=252

        From: Paul Nader <Paul.Nader@telefonica.net>
        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=log4cxx-user@logging.apache.org&msgNo=376

        Subject: Log4cxx obliterates the TZ setting...
        From: renny.koshy@rubixinfotech.com <renny.koshy@rubixinfotech.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

        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?

        Show
        Curt Arnold added a comment - Additional reports: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-dev@logging.apache.org&msgNo=252 From: Paul Nader <Paul.Nader@telefonica.net> 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=log4cxx-user@logging.apache.org&msgNo=376 Subject: Log4cxx obliterates the TZ setting... From: renny.koshy@rubixinfotech.com <renny.koshy@rubixinfotech.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 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 made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Curt Arnold added a comment -

        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.

        Show
        Curt Arnold added a comment - 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.
        Curt Arnold made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 0.9.8 [ 10782 ]
        Resolution Fixed [ 1 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        94d 2h 40m 1 Curt Arnold 13/Nov/04 02:44
        In Progress In Progress Resolved Resolved
        3m 13s 1 Curt Arnold 13/Nov/04 02:47

          People

          • Assignee:
            Curt Arnold
            Reporter:
            Curt Arnold
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development