On Wed, 28 Jan 2015 12:02:32 +0100 Rainer Jung <rainer.j...@kippdata.de> wrote:
> 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. I reviewed Noel's comments; >170.130.179.246 - - [26/Jan/2015:01:02:06 +0000] "GET /archives/ >197.156.95.99 - - [26/Jan/2015:11:02:18 +1000] "GET /ups/t568b.png >HTTP/1.1" >95.211.138.225 - - [26/Jan/2015:01:02:40 +0000] >"GET /Android-Apps.html HTTP/1.1" 144.76.247.107 - - >[26/Jan/2015:11:03:32 +1000] "GET / > >(correct time is 11:xx:xx) I presume he means 1100 hours, GMT +10. If that is the case then the 0100 hours entries are also correct relative to Zulu, GMT +/- 0.
