数据库应只存储utc时间，python读写时需显式转换：写入前用zoneinfo或pytz将本地时间转utc，读取后按需转目标时区，避免依赖数据库函数及时区误用。
数据库只存UTC时间，Python读写时必须显式转换
UTC存储是唯一靠谱做法。任何把本地时间直接塞进数据库的操作，迟早引发跨时区查询错乱、夏令时重复/跳过、统计口径不一致等问题。Python默认datetime对象是“naive”的（无时区信息），直接存进数据库等于埋雷。
实操建议：
- 写入前：用
pytz或zoneinfo（Python 3.9+）将用户输入的本地时间转成UTC再存，例如dt.astimezone(timezone.utc) - 读取后：从数据库拿到UTC时间（
datetime带tzinfo=timezone.utc），再按需转成目标时区，如dt.astimezone(ZoneInfo("Asia/Shanghai")) - 别依赖数据库函数做时区转换（如MySQL的
CONVERT_TZ），逻辑分散且难测试
用zoneinfo替代pytz，但要注意Python版本和系统时区数据
zoneinfo是Python 3.9+标准库方案，比pytz更符合直觉——它不修改原对象，而是返回新实例；pytz的localize和astimezone行为容易误用，尤其处理夏令时边界时出错率高。
实操建议：
- Python pytz，但务必避免
dt.replace(tzinfo=...)这种错误赋值，必须用tz.localize(dt) - Python ≥ 3.9？优先用
from zoneinfo import ZoneInfo，注意Linux/macOS依赖系统tzdata包，Docker镜像里常缺失，需手动安装tzdata或复制/usr/share/zoneinfo -
ZoneInfo("Asia/Shanghai")比ZoneInfo("CST")安全——后者是模糊缩写，不同系统可能指向美国中部或中国标准时间
ORM（如SQLAlchemy）字段类型选DateTime而非Time，并禁用自动时区转换
很多ORM默认对DateTime字段做隐式时区转换（比如SQLAlchemy的timezone=True参数），这会掩盖问题：你以为存的是UTC，其实ORM在入库前偷偷转了本地时区。
实操建议：
- SQLAlchemy中，数据库字段定义用
Column(DateTime, nullable=False)，**不要**加timezone=True - 确保连接URL里明确关闭驱动层转换，例如PostgreSQL加
?options=-c%20timezone%3Dutc，MySQL加?charset=utf8mb4&init_command=SET time_zone='+00:00' - Django用户：设
USE_TZ = True，且所有DateTimeField都默认按UTC存；但注意auto_now/auto_now_add生成的时间是UTC，别在模板里直接|date:"Y-m-d H:i"而不指定时区
前端传时间戳时，警惕JavaScript Date().getTime()返回的是毫秒级UTC时间
前端调new Date().getTime()得到的是毫秒时间戳（自Unix epoch起算），它本质是UTC，但开发者常误以为是本地时间，导致Python后端用datetime.fromtimestamp(ts / 1000)解析成错误的本地时间。
实操建议：
- 前后端约定：前端传ISO格式字符串（如
"2024-05-20T08:30:00.123Z"）比传时间戳更可靠，Python用datetime.fromisoformat(s)可直接解析出带tzinfo的对象 - 若必须传时间戳：后端统一用
datetime.utcfromtimestamp(ts / 1000).replace(tzinfo=timezone.utc)，而不是fromtimestamp - 浏览器
Date对象构造含时区偏移的字符串（如toISOString()）比toString()安全，后者输出本地时区文本，无法直接反解
真正麻烦的不是转换本身，而是同一份时间在日志、缓存、消息队列、前端展示多个环节里被反复转换又没标注来源时区。只要有一个环节漏掉tzinfo或搞错方向，后续所有时间计算就不可信。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
