Repository navigation
TimedRotatingFileHandler "midnight" misleading when interval > 1 #90535
Description
| BPO | 46377 |
|---|---|
| Nosy | @vsajip |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2022-01-14.13:50:48.156>
labels = ['type-feature', 'library', '3.11']
title = 'TimedRotatingFileHandler "midnight" misleading when interval > 1'
updated_at = <Date 2022-01-14.18:25:21.751>
user = 'https://bugs.python.org/mschiess'bugs.python.org fields:
activity = <Date 2022-01-14.18:25:21.751>
actor = 'mschiess'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2022-01-14.13:50:48.156>
creator = 'mschiess'
dependencies = []
files = []
hgrepos = []
issue_num = 46377
keywords = ['patch']
message_count = 5.0
messages = ['410558', '410565', '410567', '410571', '410583']
nosy_count = 3.0
nosy_names = ['vinay.sajip', 'python-dev', 'mschiess']
pr_nums = ['30599']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue46377'
versions = ['Python 3.11']Linked PRs
- gh-90535: Warn of deprecation of intervals other than 1 with when='MIDNIGHT' #98099
- gh-90535: Fix support of interval>1 in logging.TimedRotatingFileHandler #116220
- [3.12] gh-90535: Fix support of interval>1 in logging.TimedRotatingFileHandler (GH-116220) #116892
- [3.11] gh-90535: Fix support of interval>1 in logging.TimedRotatingFileHandler (GH-116220) #116893
Activity
mschiess commented on Jan 14, 2022
Using the TimedRotatingFileHandler along with "when='midnight'" and interval > 1, midnight is handled equally to "days" which is a little misleading.
Expectation:
setting when to 'midnight', the file is rotated every midnight (interval value should be ignored)
Current behavior:
If 'midnight' is given alongside with an interval greater than 1 (.e.g 5), the (internal) interval (24*60*60) is calculated with the given interval -> 24*60*60 * 5.
In my case, this led to some unforeseeable and unexpected behavior.
21 remaining items
serhiy-storchaka commented on Mar 1, 2024
I see now that the problem is that computeRollover() returns the next nearest "midnight" time, ignoring the interval parameter, while doRollover() computes the file name by stepping back interval days. And there is the same issue with the weekly rotation.
My fix #116191 perhaps affected this issue and made it worse (if you do not consider it better). Previously, in doRollover(), if computeRollover() returned the current time, self.interval was added, so the next rollover time was set after interval days or weeks. But this behavior depended on atTime and the time of running the script.
Perhaps the safest way is to implement the correct support of the interval parameter for "midnight" and weekly rotation.
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…
gh-90535: Fix support of interval>1 in logging.TimedRotatingFileHandl…
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…
[3.12] gh-90535: Fix support of interval>1 in logging.TimedRotatingFi…
[3.11] gh-90535: Fix support of interval>1 in logging.TimedRotatingFi…
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…
pythongh-90535: Fix support of interval>1 in logging.TimedRotatingFil…