For what he likes to do the cron job wouldn't work. I will explain why:
As far as i found out until now, there are three alternatives how a webserver may work with PHP.
The first method is to use PHP as CGI Wrapper. Using this method, the webserver will create an instance of the php interpreter upon each request and close it afterwards. Like this, no persistence is given, no objects may be shared over more than one request.
The second method (and widly used these days) uses PHP as a Modul in a multi-process/multi-threaded webserver. Each request is passed from the parent process (kind of request handler) to one of it's childs. Each of this child processes is persistent, means within one of these child processes an object may life for a longer period than the request it was created in.
Third method is a plugin for a multi-threaded webserver. This will work very similar to the second alternativ
This means, that, as far as i understand now, there is no such thing as single persistent runtime environment on the webserver side that would allow to create objects and let them life there for later use. This would only work in the second method if there is only one parent and maybe one but no more child processes.
Do i get this right?
Back to the LogFile and cron job problem - running a cron job from outside one of the webserver's processes you will have no chance to get a reference to the current instance of the LogFile object to call its swap() method (you will only be able to create a new Instance of the LogFile object with the same parameter an than swap the LogFile, but the LogFile object in the webserver would not know about this). So this couldn't ever work.
But also his approach witha time object will not work because of the missing server-wide persistent runtime env.
But, what i am still wondering about is, if there in no server-wide persistent runtime env, how then do sessions work? Session objects seem to be persistently available no matter of what child process is handling the request......