设置：Django上的多个站点位于同一组服务器上，由同一组Apache进程提供服务。有些地方是东部TZ;有些是中环。数据库是在单独的服务器上运行的PSQL。
当我开始时，我没有考虑各个网站如何处理时区;我想我在Django中看到了TIMEZONE设置并且只是认为它''处理它'。现在我看到了裂缝。
第一个问题：时区似乎在东部和中部之间来回翻转。我在这个网站上搜索的理解是，因为TZ的os environ var被设置为Apache进程，这取决于它处理请求的Django站点，以及该进程是否处理了另一个站点的请求。 TZ，时区错了。我相信我在这里找到的解决方案是不同时区的网站需要有不同的流程组来为它们服务。如果错误请更正。
第二个问题：在Linux上本地，我用我的一个中心时间网站（我在东部）做了一个./manage.py运行服务器。我创建了一个资产，其发布日期在管理员中正确显示为一小时。查看实际的PostgresSQL条目，发布日期的时区仍然列为-04。 Postgres只使用服务器/计算机本身的时区而忽略Django中的任何TZ设置吗？因此，东部时间保存在Postgres服务器上的所有条目将显示为-04或-05，具体取决于夏令时？
如果有其他人处理过这样的事情，建议表示赞赏。即使我拆分了中心站点的Apache进程，使得他们的TZ设置没有交叉，我仍然有Postgres问题需要处理。然后我很好奇;如果PSQL时间戳是Central，而TZ设置是Eastern，那么，datetime字段是否考虑了TZ？也就是说，如果您在Django设置为EST时执行datetime.datetime.now（），并且它返回2:00 PM，那么您可以根据其发布日期小于该结果来过滤内容，它是否仅仅考虑TZ寻找发布时间是CST或更早的下午1:00的内容？
答案 0 :(得分：2)
以下是Django和Postgres中有关时区处理的一些细节，但我强烈建议在后端专门处理UTC，并在呈现UTC时间戳时仅转换到前端的本地时区给用户。在Python中，您可以通过datetime.datetime.utcnow()获取UTC的当前时间。我甚至将我的服务器放在UTC时区，但这不是绝对必要的。
多个时区在Django中效果不佳;见this ticket。 Python标准库中的日期时间对象是时区的天真，你需要像pytz这样的库来修复它，但据我所知，Django仍然会返回天真的日期时间对象，而不是你可以用pytz构建的时区感知对象。
Postgres会检查几个地方以确定时区，包括TZ环境变量，但是TZ必须在postgres过程的环境中：
PostgreSQL 8.5.3。时区
如果未指定时区 postgresql.conf也不是postmaster 命令行开关，服务器 试图使用TZ的值 环境变量作为默认值 时区。如果TZ未定义或是 没有任何已知的时区名称 到服务器尝试的PostgreSQL 确定操作系统 通过检查默认时区 C库函数的行为 当地时间（）。默认时区是 被选为最接近的匹配 PostgreSQL的已知时区。