直接使用WHERE created_at > '2024-01-01'会因时区隐式转换导致结果错误，正确做法是显式指定时区如'2024-01-01T00:00:00+00'或通过AT TIME ZONE转换为UTC再比较。
WHERE条件里直接用WHERE created_at > '2024-01-01'会出错
PostgreSQL、MySQL 8.0+ 或 SQLite 中，如果 created_at 是 timestamptz（带时区的时间戳），字符串字面量 '2024-01-01' 默认按当前会话时区解析，不是 UTC。你查出来的结果可能比预期多或少一天。
- PostgreSQL 会把
'2024-01-01'当作本地时区时间，再转成 UTC 存储值做比较 —— 如果你的服务器在东八区，'2024-01-01'实际对应 UTC 的'2023-12-31 16:00:00' - MySQL 8.0+ 的
TIMESTAMP类型也隐式转换时区，但行为依赖time_zone系统变量，容易不一致 - 安全写法是显式指定时区：
WHERE created_at > '2024-01-01T00:00:00+00'（ISO 8601 带偏移）或WHERE created_at > '2024-01-01'::timestamptz AT TIME ZONE 'UTC'（PostgreSQL）
用AT TIME ZONE转换查询结果时要注意方向
AT TIME ZONE 不是“把时间改成某个时区”，而是“把带时区的时间戳，以另一个时区的本地时间形式展示”。很多人误以为 created_at AT TIME ZONE 'Asia/Shanghai' 是把 UTC 时间转成北京时间，其实它只是把存储的 UTC 值，按上海时区偏移重新格式化输出 —— 值本身没变，只是显示方式变了。
- 想查“北京时间 2024-01-01 00:00:00 之后的数据”，不能写
WHERE created_at AT TIME ZONE 'Asia/Shanghai' > '2024-01-01'，因为这会先转显示再比较，索引失效且逻辑绕弯 - 正确做法是把目标时间转成 UTC：
WHERE created_at > '2024-01-01'::timestamptz AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC'（PostgreSQL），或更直白地用WHERE created_at > '2024-01-01 00:00:00+08' - MySQL 没有标准
AT TIME ZONE，得用CONVERT_TZ('2024-01-01', '+08:00', '+00:00')配合TIMESTAMP字段
应用层传时间参数时别依赖数据库默认时区
ORM（比如 Django、SQLAlchemy）或 JDBC 连接串里若没显式设时区，Java/Python 可能用系统本地时区构造 Timestamp，再发给数据库。数据库收到后可能二次转换，导致存入值和预期不符。
- Django：确保
settings.py中TIME_ZONE = 'UTC'，且数据库连接加OPTIONS={'init_command': "SET time_zone='+00:00'"}（MySQL）或使用timestamptz（PostgreSQL） - JDBC URL 加
?serverTimezone=UTC&useTimezone=true（MySQL），PostgreSQL 则推荐连接时执行SET TIME ZONE 'UTC' - Node.js pg 模块默认把 JS Date 当 UTC 处理，但若传字符串，仍需确保是 ISO 格式带偏移，如
'2024-01-01T00:00:00Z'
跨时区聚合（如按天统计）必须统一到一个基准时区
用 DATE(created_at) 或 GROUP BY created_at::date 在 timestamptz 字段上会按数据库当前时区切分，不是按用户所在时区，也不是按 UTC —— 这会导致不同地区用户看到的“当天”数据不一致。
- 想按 UTC 日统计：
GROUP BY (created_at AT TIME ZONE 'UTC')::date - 想按用户本地日统计（假设前端传了时区）：
GROUP BY (created_at AT TIME ZONE %s)::date，其中%s是用户时区名（如'Asia/Shanghai'） - 注意：这类表达式无法走索引，大数据量时建议加生成列或物化视图预计算
