Django 应用程序中的 datetime.now() 变坏了答案

【问题标题】：datetime.now() in Django application goes badDjango 应用程序中的 datetime.now() 变坏了
【发布时间】：2010-10-27 09:31:45
【问题描述】：

我在部署 Django 应用程序后遇到了一些问题。我在 ubuntu 服务器上使用 Apache + mod-wsgi。在我重新启动服务器后一段时间，时间变为 foobar，大约 -10 小时是错误的。我制作了一个 Django 视图，如下所示：

def servertime():
  return HttpResponse( datetime.now() )

在我重新启动服务器并检查显示该视图的 url 后，它首先看起来没问题。然后在某一时刻，它有时给出正确的时间，有时不给出，后来它总是给出错误的时间。但是服务器时间是正确的。

有什么线索吗？我用谷歌搜索它没有运气。

【问题讨论】：

正好是 10 小时吗？可能是时区问题。
我也尝试过同样的错误。似乎datetime.now() 方法在服务器启动时计算一次，之后是恒定的（对于日期而不是小时）。确实非常奇怪和意想不到的行为。我将尝试按照标记答案中的建议将 wsgi_mod 设置为守护程序模式。而且，事实上，我同时也在运行一个 PHP 应用程序......
这是 Django 1.1 的问题，所以 Django 的新时区支持可能不再是问题。

标签： python django apache datetime mod-wsgi

【解决方案1】：

我也可以看看你的 urls.py 吗？

类似的行为曾经让我难过...

结果是我的 urls.py 调用视图的方式。 Python 运行了一次 datetime.now() 并将其存储起来以备将来调用，再也不会真正调用它。这就是为什么 django 开发人员必须实现将函数而不是函数调用传递给模型的默认值的能力，因为它将采用函数的第一次调用并使用它直到 python 重新启动。

您的行为听起来第一次是正确的，因为它是第一次调用视图。有时它是不正确的，因为它再次获得了相同的日期。然后它再次随机正确，因为您的 apache 可能为它启动了另一个工作进程，并且当您在处理请求的进程之间被弹跳时可能会发生这种疯狂。

【讨论】：

【解决方案2】：

我发现将 wsgi 置于守护程序模式是可行的。不知道为什么，但确实如此。似乎一些新创建的进程搞砸了时间。

【讨论】：

很可能是因为您同时在 Apache 中运行其他一些 Web 应用程序，例如 PHP，并且该应用程序正在将时区更改为另一个值并与 Django 应用程序发生冲突。此问题记录在 code.google.com/p/modwsgi/wiki/… 的 mod_wsgi 文档中。

【解决方案3】：

datetime.now() 可能在您的类被实例化时被评估一次。尝试删除括号，以便返回函数 datetime.now 并对其进行评估。我在为我的 DateTimeFields 设置默认值时遇到了类似的问题，并写了我的解决方案 here。

【讨论】：

【解决方案4】：

也许服务器正在服务器启动时评估 datetime.now()，尝试通过模板使其变得惰性或在视图中使用变量。

看看这个blog post。

【讨论】：

【解决方案5】：

Django 根据您的设置变量 TIME_ZONE 设置系统时区。在运行具有不同 TIME_ZONE 设置的多个 Django 实例时，这可能会导致各种混乱。

这就是 Django 所做的：

os.environ['TZ'] = self.TIME_ZONE

以上答案：

“我发现将 wsgi 置于守护模式是可行的”

不适合我...

我想我不再使用 django 内置的 TIME_ZONE。

【讨论】：

【解决方案6】：

您可能需要像这样指定内容类型

def servertime():
  return HttpResponse( datetime.now(), content_type="text/plain" )

另一个想法：

它可能不起作用，因为 datetime.now() 返回一个 datetime 对象。试试这个：

def servertime():
  return HttpResponse( str(datetime.now()), content_type="text/plain" )

【讨论】：

【解决方案7】：

尝试在 settings.py 中设置您的时区（TIME_ZONE 变量）

这对我有用。

【讨论】：