Am 27.01.2015 um 21:41 schrieb William A. Rowe Jr.:
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.
But wasn't the time itself also wrong? I had the impression the observation was not only about timezone, but wrong timezone was easiest to detect. I could be wrong but it looked like the timezone shift would not have explained the change in time stamp in the same log entries.
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.
Regards, Rainer
