Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/django/22.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Python 如何更改Django日志记录的日期格式?_Python_Django_Logging - Fatal编程技术网

Python 如何更改Django日志记录的日期格式?

Python 如何更改Django日志记录的日期格式?,python,django,logging,Python,Django,Logging,答案中的注释表示,您应该能够自定义登录Django的日期格式: 请注意,如果您使用dictConfig方法配置日志记录(例如,如果您使用Django),则可以使用格式化程序的“datefmt”dict键进行设置。请参阅:Django日志记录配置,日志记录模块:字典模式详细信息 但是,它不起作用: # settings.py LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'formatters':

答案中的注释表示,您应该能够自定义登录Django的日期格式:

请注意,如果您使用dictConfig方法配置日志记录(例如,如果您使用Django),则可以使用格式化程序的“datefmt”dict键进行设置。请参阅:Django日志记录配置,日志记录模块:字典模式详细信息

但是,它不起作用:

# settings.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'django.server': { # duplicate of default for django.server
            '()': 'django.utils.log.ServerFormatter',
            'format': '[{server_time}] {message}',
            'style': '{',
            'datefmt' : '%Y-%m-%d %H:%M:%S'
            }
}
这也不起作用:

# settings.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'default': {
            'datefmt' : '%Y-%m-%d %H:%M:%S'
            },
}
在这两种情况下,我仍然获得默认的日志日期格式:

[13/Mar/2019 21:53:05] "GET / HTTP/1.1" 200 16808
请注意,在源代码中,应该传递并使用
datefmt
,但情况似乎并非如此:

使用Python 3.6和Django 2.1


更新:

当我将其包括在我的
设置.py中时,如下所述:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'django.server': {
            '()': 'django.utils.log.ServerFormatter',
            'format': '[{server_time}] {message}',
            'datefmt' : '%Y-%m-%d %H:%M:%S',
            'style': '{',
        }
}
然后编辑文件
conda//lib/python3.6/site packages/django/utils/log.py
,如下所示:

class ServerFormatter(logging.Formatter):
    def __init__(self, *args, **kwargs):
        self.style = color_style()
        super().__init__(*args, **kwargs)
        print("self.datefmt", self.datefmt)
我在控制台中收到如下消息,表明我实际上正在正确传播
datefmt

$ python manage.py runserver
self.datefmt %Y-%m-%d %H:%M:%S
self.datefmt %Y-%m-%d %H:%M:%S
Performing system checks...

System check identified no issues (0 silenced).
March 13, 2019 - 23:43:50
Django version 2.1.2, using settings 'webapp.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
[13/Mar/2019 23:45:14] "GET / HTTP/1.1" 200 16808
可能错误与
django/utils/log.py
中的这一行有关

if self.uses_server_time() and not hasattr(record, 'server_time'):
            record.server_time = self.formatTime(record, self.datefmt)
^无论我做什么,这项检查似乎都不会被触发,因为
not hasattr(record,'server\u time')
总是计算为
False
,因为
record
默认情况下已经有
server\u time
,它似乎来自
Django/core/servers/basehttp.py
中Django代码的这一部分:

class WSGIRequestHandler(simple_server.WSGIRequestHandler):
...
...
    def log_message(self, format, *args):
        extra = {
            'request': self.request,
            'server_time': self.log_date_time_string(),
        }
def log_date_time_string(self):
    """Return the current time formatted for logging."""
    now = time.time()
    year, month, day, hh, mm, ss, x, y, z = time.localtime(now)
    s = "%02d/%3s/%04d %02d:%02d:%02d" % (
            day, self.monthname[month], year, hh, mm, ss)
    return s
其中
simple\u server.WSGIRequestHandler.log\u date\u time\u string()
来自
wsgiref
包。但是,该包不包含对函数
log\u date\u time\u string()
的任何引用,它似乎直接来自Python内置的
http
库(
conda//lib/python3.6/http/server.py
):

^此处的日期格式是硬编码到库中的,似乎无法更改


所以。。。这一切该怎么办?我错过什么了吗?这是Django的某种bug吗?除非我弄错了,否则无法基于此覆盖此
datefmt

这是一个很好的详细调查。确保你的研究包括Django票证追踪系统。搜索
站点:code.djangoproject.com datefmt
的第一次点击显示这是一个错误


该记录单显示了一种可能的解决方法,即使用
asctime
而不是
server\u time

该字典不应该改为
DEFAULT\u LOGGING
吗?将其更改为
DEFAULT\u LOGGING
似乎不会对此产生影响