PostgreSQL存储UTC数据时的SQLAlchemy日期时间问题

核心结论：保留timestamp with time zone存储，绝不提前转时区 #

• 必须保留数据库字段的timestamptz类型，这是行业通用标准。哪怕当前只用美国中部时区，未来要扩展到其他时区时，只需要修改筛选逻辑，不用动历史数据。PostgreSQL的timestamptz本质存储的是UTC时间，PG Admin显示本地时区只是客户端的自动转换，API返回UTC时间是正确行为（前端可按需转换，或后端统一处理后返回）。
• 绝对不要在存入数据库前把时间转成中部时区，这会把数据和特定时区绑定，后续扩展或调整时区时会导致数据混乱，维护成本极高。

正确的“今日”赛事筛选代码 #

方法1：Python层面计算时区范围（适合需要在代码里复用时间范围的场景） #

from datetime import datetime, timedelta
import pytz
from your_app import Event  # 替换成你的Event模型导入

# 获取美国中部时区对象
central_tz = pytz.timezone('US/Central')

# 计算中部时区今日的起始（00:00:00）和结束（次日00:00:00）
today_start_central = central_tz.localize(
    datetime.now().replace(hour=0, minute=0, second=0, microsecond=0)
)
today_end_central = today_start_central + timedelta(days=1)

# 转换为UTC时间，和数据库的timestamptz字段比较
today_start_utc = today_start_central.astimezone(pytz.utc)
today_end_utc = today_end_central.astimezone(pytz.utc)

# 执行筛选
events = Event.query.filter(
    Event.gamedate >= today_start_utc,
    Event.gamedate < today_end_utc
).all()

方法2：数据库层面直接处理（更高效，减少Python侧的时区计算） #

利用PostgreSQL的时区函数，直接在SQL中转换并筛选：

from sqlalchemy import func
from your_app import Event

events = Event.query.filter(
    # 将gamedate转换为中部时区后，截取日期部分等于当前中部时区的日期
    func.date(func.timezone('US/Central', Event.gamedate)) == func.current_date()
).all()

为什么你的原代码不生效？ #

你之前的代码用datetime.today()获取本地时间后转UTC，实际上是取了UTC时区的“今日”范围，而非美国中部时区的。比如中部时区的今日0点对应UTC的6点，你的代码会包含UTC昨天6点到明天6点的赛事，和你需要的“中部时区今日”完全不符。

内容的提问来源于stack exchange，提问作者Eric K