部署 Django 应用程序后，我遇到了一些问题。我在 ubuntu 服务器上使用 Apache + mod-wsgi。在我重新启动服务器一段时间后，时间变为 foobar，大约 -10 小时是错误的。我制作了一个 Django 视图，如下所示：
def servertime():
return HttpResponse( datetime.now() )
在我重新启动服务器并检查显示该视图的 url 后，它首先看起来没问题。然后在某一时刻，它有时给出正确的时间，有时不给出，后来它总是给出错误的时间。服务器时间是正确的。
有什么线索吗？我用谷歌搜索它没有运气。
我也可以看看你的 urls.py 吗？
类似的行为曾经让我难过一次……
结果是我的 urls.py 调用视图的方式。Python 运行了一次 datetime.now() 并将其存储起来以备将来调用，再也不会真正调用它。这就是为什么 django 开发人员必须实现将函数而不是函数调用传递给模型默认值的能力，因为它将采用函数的第一次调用并使用它，直到重新启动 python。
您的行为听起来第一次是正确的，因为它是第一次调用视图。有时它是不正确的，因为它再次获得了相同的日期。然后它再次随机正确，因为您的 apache 可能为它启动了另一个工作进程，并且当您在处理请求的进程之间被反弹时，可能会发生这种疯狂。
我发现将 wsgi 置于守护程序模式是可行的。不知道为什么，但确实如此。似乎一些新创建的进程把时间搞砸了。
当您的类被实例化时， datetime.now() 可能会被评估一次。尝试删除括号，以便返回函数 datetime.now 并对其进行评估。我在为我的 DateTimeFields 设置默认值时遇到了类似的问题，并在此处编写了我的解决方案。
也许服务器正在服务器启动时评估 datetime.now()，尝试通过模板使其变得惰性或在视图中使用变量。
看看这篇博文。
Django 根据您的设置变量 TIME_ZONE 设置系统时区。当运行具有不同 TIME_ZONE 设置的多个 Django 实例时，这可能会导致各种混乱。
这就是 Django 所做的：
os.environ['TZ'] = self.TIME_ZONE
上面的答案：
“我发现将 wsgi 置于守护进程模式是可行的”
对我不起作用...
我想我不再使用 TIME_ZONE 中内置的 django 了。
您可能需要像这样指定内容类型
def servertime():
return HttpResponse( datetime.now(), content_type="text/plain" )
另一个想法：
它可能不起作用，因为 datetime.now() 返回一个 datetime 对象。试试这个：
def servertime():
return HttpResponse( str(datetime.now()), content_type="text/plain" )
尝试在 settings.py 中设置您的时区（TIME_ZONE 变量）
这对我有用。