如何配置USE_TZ与TIME_ZONE以解决Python Django DateTimeField时区不一致问题？

本文共计1127个文字，预计阅读时间需要5分钟。

`USE_TZ=True` 是 Django 中用于设置时区的一个配置项。它表示 Django 应该使用时区信息，而不是将所有时间都视为 UTC 时间。通过设置 `USE_TZ=True`，Django 会自动将数据库中存储的 UTC 时间转换为当前时区的时间。

为什么 USE_TZ = True 必须开启

Django 的 DateTimeField 在 USE_TZ = False 下存的是“本地时间”，但这个“本地”是服务器所在操作系统的时区（比如 Asia/Shanghai），而 Python 解释器、数据库连接、Django 启动环境可能各自读取不同的时区配置，导致同一时间值在 ORM 查询、Admin 显示、API 序列化中表现不一致。

• 数据库里存的是 2024-05-10 14:30:00，但没带时区信息，Django 不知道它本意是 UTC 还是 CST
• datetime.now() 在不同模块调用可能返回带/不带 tzinfo 的对象，DateTimeField 赋值时静默丢弃时区，引发比较异常
• PostgreSQL 的 timestamptz 字段与 Django 的 naive datetime 混用，会触发警告甚至报错：RuntimeWarning: DateTimeField received a naive datetime

TIME_ZONE 只影响默认时区显示，不控制存储逻辑

TIME_ZONE = 'Asia/Shanghai' 的作用，是在 USE_TZ = True 前提下，为未显式指定时区的 datetime 对象提供“默认解释规则”，以及控制 Admin、模板中 {% now %} 等的显示格式。它不会让数据库存“东八区时间”，也不会把 UTC 存储值自动转成 CST 再返回。

• 数据库始终以 UTC 存储（USE_TZ = True 时）
• TIME_ZONE 只在渲染层起作用：比如 timezone.now() 返回的是带 UTC tzinfo 的对象，但 timezone.localtime() 会按 TIME_ZONE 转成带 Asia/Shanghai tzinfo 的对象
• 模板中 {{ obj.created_at }} 默认显示为 TIME_ZONE 时区时间；若需强制显示 UTC，得写 {{ obj.created_at|date:"Y-m-d H:i:s T" }} 并确保 created_at 是 aware datetime

常见错误场景与修复写法

最典型的坑是手动构造 datetime 并直接赋给 DateTimeField：

立即学习“Python免费学习笔记（深入）”；

# ❌ 错误：naive datetime，USE_TZ=True 时会报 warning 或静默转成 UTC（按系统本地时区解释） obj.published_at = datetime(2024, 5, 10, 14, 30) <h1>✅ 正确：显式绑定时区</h1><p>from django.utils import timezone obj.published_at = timezone.make_aware(datetime(2024, 5, 10, 14, 30), timezone.get_current_timezone())</p><h1>✅ 更推荐：统一用 timezone.now() 或 timezone.localtime()</h1><p>obj.published_at = timezone.now() # UTC obj.published_at = timezone.localtime() # 当前 TIME_ZONE 时区时间（aware）</p><h1>✅ API 接收前端 ISO 格式时间时（如 "2024-05-10T14:30:00+08:00"）</h1><p>from dateutil import parser dt = parser.isoparse("2024-05-10T14:30:00+08:00") # 自动带 tzinfo obj.published_at = dt # 直接赋值，Django 会自动转换为 UTC 存储

另一个高频问题是数据库迁移后旧数据没处理：

• 已有大量 naive datetime 存在数据库中，开启 USE_TZ = True 后首次读取会报 ValueError: Non-naive datetime...
• 需用 raw SQL 或 Django migration 批量补 tzinfo，例如假设所有旧数据本意都是 Asia/Shanghai：

UPDATE myapp_mymodel SET created_at = created_at AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC';

部署时最容易被忽略的点

本地开发 USE_TZ = True 没问题，一上生产就乱，往往是因为：

• 服务器系统时区（/etc/timezone）和 TIME_ZONE 配置不一致，导致 timezone.get_current_timezone() 返回意外结果
• Gunicorn / uWSGI 启动时没设 TZ 环境变量，子进程继承了宿主机错误时区
• 数据库连接层（如 psycopg2）的 options 里写了 -c timezone=utc，但 Django 已经在做时区转换，造成双重转换

建议在 settings.py 开头加一行验证：

import os os.environ['TZ'] = 'UTC' # 强制 Python time 模块用 UTC

然后确保所有 datetime 构造都走 timezone 模块，而不是 datetime.datetime 原生方法。