On Mon, 26 Jan 2015 16:43:29 -0500 Jim Jagielski <j...@jagunet.com> wrote:
> I'll give the vote another 24 hours... I don't consider the > UTC/logging issue enough to hold the release, unless it appears > a symptom of a more serious problem, but want to give us some > more time to try to get a handle on it. I'd agree. My thoughts on OP's posts, that their specific PHP scripts are modifying the global timezone locale, notably process-by-process, and these are not reset at the end of processing. In the case of the event or worker MPM it's impossible to do this without a thread-local implementation of time.h (as Windows and Netware have long had) while even with prefork, depending on which process handles a given request, this php script will apparently have left the server in one state or another, leading to 'flipping' the timezone from log entry to entry. It's [mostly] harmless. If a given log entry is 'zinged' by a change of the timezone offset in between formatting the zone and formatting the time and the date, this could yield some wild jumps. But as the PHP crew long demoted thread saftey from experimental to deprecated (IIUC), then I'm afraid we simply have to take them at their word. The universally endorsed php processing mechanism is now fcgi. There is a possibility that OP's had actually rebuilt APR (from the -deps), even with the very same APR version, which resulting in some different autoconf detection on their platform relative to time.h function handling. It would be worth close inspection of their own config.cache files of old and new APR builds to say for sure.
