Question

部署之后，我遇到了Django应用程序的一些问题。我在ubuntu服务器上使用Apache + mod-wsgi。我重新启动服务器一段时间后，时间变为foobar，大约-10小时就错了。我创建了一个看起来像的Django视图：

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

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

任何线索？我没有运气就google了。

Answer 1

我也能看到你的urls.py吗？

类似的行为让我难过一次......

结果是我的urls.py调用视图的方式。 Python运行了datetime.now（）一次并将其存储以供将来调用，从不再真正调用它。这就是为什么django开发人员必须实现将函数而不是函数调用传递给模型的默认值的能力，因为它将首先调用函数并在重新启动python之前使用它。

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

Answer 2

我发现将wsgi放在守护进程模式下可行。不知道为什么，但确实如此。似乎有些新创建的流程会缩短时间。

Answer 3

当您的类被实例化时，

datetime.now（）可能被评估一次。尝试删除括号，以便返回函数datetime.now并进行THEN计算。我在设置DateTimeFields的默认值时遇到了类似的问题，并写了我的解决方案here。

Answer 4

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

看看这个blog post。

Answer 5

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

这就是Django的作用：

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

以上回答：

“我发现将wsgi放入守护进程模式”

对我不起作用......

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

Answer 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" )

Answer 7

尝试在settings.py

中设置您的时区（TIME_ZONE变量）

这对我有用。