use_tz = true 是 django 时区处理的强制要求，否则会导致存储、查询、显示不一致；开启后数据库统一存 utc，time_zone 仅影响显示层，所有 datetime 操作须使用 django.utils.timezone 模块。
USE_TZ = True 是 Django 时区问题的分水岭，不是“开了更好”，而是“不开必出错”——尤其当你的应用要部署到不同时区服务器、或用户分布在多个时区时。
为什么 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()返回的是带UTCtzinfo 的对象，但timezone.localtime()会按TIME_ZONE转成带Asia/Shanghaitzinfo 的对象 - 模板中
{{ obj.created_at }}默认显示为TIME_ZONE时区时间；若需强制显示 UTC，得写{{ obj.created_at|date:"Y-m-d H:i:s T" }}并确保created_at是 aware datetime
常见错误场景与修复写法
最典型的坑是手动构造 datetime 并直接赋给 DateTimeField：
# ❌ 错误：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 存储
</p>
另一个高频问题是数据库迁移后旧数据没处理：
- 已有大量 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 原生方法。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
