# Logging TimedRotatingFileHandler never rotates in certain cases

**URL:** <https://discuss.python.org/t/logging-timedrotatingfilehandler-never-rotates-in-certain-cases/14747>\
**Category:** Python Help\
**Created:** [March 31, 2022, 2:04pm UTC](https://discuss.python.org/t/logging-timedrotatingfilehandler-never-rotates-in-certain-cases/14747 "2022-03-31T14:04:15Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![silmaril](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/silmaril/32/5659_2.png) [@silmaril](https://discuss.python.org/u/silmaril)\
**Post date:** [March 31, 2022, 2:04pm UTC](https://discuss.python.org/t/logging-timedrotatingfilehandler-never-rotates-in-certain-cases/14747/1 "2022-03-31T14:04:15Z")

</div>

I have a problem understanding why things were designed as they are in the [TimedRotatingFileHandler](https://docs.python.org/3.10/library/logging.handlers.html#timedrotatingfilehandler).

It says there:

> When computing the next rollover time for the first time (when the handler is created), the last modification time of an existing log file, or else the current time, is used to compute when the next rotation will occur.

Why do we use the [last modification time (`st_mtime`)](https://docs.python.org/3.10/library/os.html#os.stat_result.st_mtime) and not the [file creation time (`st_ctime`)](https://docs.python.org/3.10/library/os.html#os.stat_result.st_ctime) here?

Consider this use case:  
_A script gets started frequently (say every 5 minutes) and only runs for a few seconds, logging some lines to the log file in each run._

If the TimedRotatingFileHandler is configured to rotate every hour, the log file will never be rotated in this case!

Every run will update the `st_mtime` of the file so the next run considers it too new to rotate.

To trigger a rotation we need a break of the configured interval, where the script does not run.

Is this really the intended behaviour?

If we used `st_ctime` instead of `st_mtime` , rotation would happen when the file gets older than the configured interval, no matter how often it was changed in between.

For scripts running continuously, this wouldn’t make a big difference, but for scripts that get started frequently it may be the difference between a rotation that works an one that never rotates at all.

This problem seems to be the same for values of `when in ['S', 'M', 'H', 'D']`. It does not matter for `midnight` or `W{0-6}`, because those use other algorithms to determine rotation times.

What do you think about this?  
Is this something that should be improved or am I missing a point?

---

_[View the full topic](https://discuss.python.org/t/logging-timedrotatingfilehandler-never-rotates-in-certain-cases/14747)._