[rt-users] Timestamps when logging to a file

[Jim Meyer]

Hello!

On Mon, 2005-12-12 at 20:08, Mike Friedman wrote:
> I was hoping that there is some other module that is influencing the date 
> in the logs in a more subtle way, perhaps not calling gmtime directly.

Seems unlikely if the format is precisely the same. That or someone went
to great lengths to match the format and write to the same file without
calling the Logger object.

Have you added any Contribs? ;]

> Or, maybe RT.pm is the only responsible module, but I need to do more than 
> just copy it to local/lib. (Unlike mason components, there doesn't seem to 
> be a cache that needs to be deleted.  Besides, I am getting localtime in 
> most of my log messages, it's just that about 1/3 of them are still using 
> GMT).

Hmmm. Any discernible pattern? What type of events are logging with
wrong dates?

Meanwhile, looking at the code, I see that the gmtime() calls are in
anonymous coderefs used as callbacks by the Log::Dispatch object. This
gives me two questions, both about bases I'm sure you've already touched
but I have to ask:

1. You've stopped and started your RT instance? (not restart, but
   stop then start)

2. Did you change both instances of the gmtime call in that file?
   If not, you might frob that to see if the problem disappears.

Finally, the only other snippet of code which might relate is in
RT::Date, where there's a selector according to source of the time
string:

    #Dateamnip strings aren't in GMT.
    if ( $args{'Format'} =~ /^datemanip$/i ) {
        $self->Unix(
            timelocal( $sec, $min, $hours, $mday, $mon, $year )
        );
    }
    #ISO and SQL dates are in GMT
    else {
        $self->Unix(
            timegm( $sec, $min, $hours, $mday, $mon, $year ) 
        );
    }

Is it possible that some time string is being de-stringified according
to these rules when you've changed the way the string was composed?
Seems like wild goose chase, but that's the only other moderately
obvious place.

Late-at-workily yours,

--j
-- 
Jim Meyer, Geek at Large                                    purp at acm.org