> Well, what's the need to rotate based on time when you just run scripts sporadically or they're very short-lived? Not trying to argue, just trying to understand.
> Yes, but generally daemons are long-lived relative to the rotation interval, aren't they? "From time to time" certainly implies that to me.

In one of our use-cases, where I faced with this bug/behaviour of TimedRotatingFileHandler, we are using it in a daemon for daily logrotate. The aim is to have the logs separated day by day, just like the majority of our other components running on a linux. We've just realized that some days are missing from the series of logs and the investigation led to the service restart and the MTIME checking that we are talking about here. When a logger is configured to rotate daily one just simply assume that it will rotate daily regardless the daemon restart. (As en extreme(?) example, when a the system - and the daemon of course - is restarted each day - or just never running for a whole day - and btw it logs often, the log file won't be ever rotated and can inrease over every limits.)

I've quickly googled around and found someone who execute some logic from cron and expects the loghandler to rotate his files, that wouldn't happened for the same reason:
https://stackoverflow.com/questions/30569164/logging-handler-timedrotatingfilehandler-never-rotates-the-log

> I just checked - the relevant code (using MTIME) was added in 2010, as a fix for bpo-8117 - around the time that Python 2.6 was released.
As I understand bpo-8117, the goal was to do the rollover even after script restarts. (To be frank, only an extreme case was mentioned in the issue opener entry, when the rollover period had been reached when the script wasn't running.) I believe for this purpose MTIME wasn't the best choice, but using CTIME instead would make the script do what is expected to.

> I take it you mean TimedRotatingFileHandler. Certainly it assumes that the script might be restarted, which is why it opens the file in append mode.

> If the computation using MTIME were changed to use CTIME, that would be a behaviour change, which could conceivably break someone's code that relied on current behaviour (unlikely, but you just never know). I've no other objection to using CTIME rather than MTIME - perhaps I'm just being hyper-cautious about breakage?

You are far better and more experienced in maintaining widely used opensource codebases so I wouldn't argue with you, but... :)

- In case of scripts that create the log file for themselves the change would have no effect.
- In case of scripts that are using already existing files for logging (by opening them for append) could change the behaviour, but just slighly. The first rollover would happen before adding the first new log line if the file age reached the configured time, and not when the age of last log line written to the file before having the script started reached the same value. No further rotation would be effected.

I _believe_ no one expects the current initial behaviour in case of resumed log files, and for sure, the documentation doesn't cover this part so I don't know how to proceed.

I _believe_ (again) that changing the behaviour wouldn't break the script outside, but rather would help them working the way how the developers originally assumed they did.