分组结果错位主因是未先转时区再截断：UTC时间直接DATE()会比北京时间晚8小时，导致日期差一天；须用CONVERT_TZ（MySQL）、AT TIME ZONE（PostgreSQL）等原生函数转换后再截断。
直接说结论：分组结果错位，90%是因为没把时间先转到目标时区再截断，而是直接对 UTC 或服务器本地时间用 DATE()、DATE_TRUNC() 之类函数。
GROUP BY DATE(created_at) 为什么总差一天？
因为 created_at 存的是 UTC，而你的业务统计要按“北京时间当天”算。直接 DATE(created_at) 相当于把 UTC 时间当成本地时间切分——比如 UTC 2026-08-10 16:00:00 是北京时间 2026-08-11 00:00:00，DATE() 会返回 '2026-08-10'，但用户要的是 '2026-08-11'。
- MySQL 必须用
CONVERT_TZ(created_at, '+00:00', '+08:00')先转时区，再套DATE() - PostgreSQL 要用
(created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai')::DATE，不能省略中间的AT TIME ZONE 'UTC' - SQL Server 若字段是
DATETIME2（无时区），得先TODATETIMEOFFSET(created_at, '+00:00')，再链式转换 - 别依赖
CURRENT_TIMEZONE或数据库默认时区，会随会话或配置漂移
按小时/15分钟分组时，时区不对齐会导致切片偏移
比如想按“北京时间每小时一组”，但用 DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')，结果发现 00:00–00:59 的数据跑到了 08:00–08:59 组里——这是因为 created_at 是 UTC，DATE_FORMAT 按服务器时区解释了它。
- MySQL 正确做法：先转时区，再算时间戳切片
FLOOR((UNIX_TIMESTAMP(CONVERT_TZ(created_at, '+00:00', '+08:00')) - UNIX_TIMESTAMP(CURDATE())) / 3600) - PostgreSQL 别用
DATE_TRUNC('hour', created_at)直接截，得写成DATE_TRUNC('hour', created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai') - 所有计算中，基准时间（如当日 0 点）必须和数据时区一致；用
CURDATE()或CURRENT_DATE前务必确认它们返回的是哪个时区的日期
PostgreSQL 报表报错 “invalid input syntax for type interval” 怎么办？
这是 EspoCRM 等系统在生成带小数小时偏移（如 +05:30）的 SQL 时，拼出了 INTERVAL 'HOUR 5.5' 这种非法语法。PostgreSQL 只认 INTERVAL '5 hours 30 minutes' 或 INTERVAL '330 minutes'。
- 临时绕过：在 PostgreSQL 中执行
SET timezone = 'UTC';，避免生成带小数偏移的 SQL - 更稳妥的是改应用层逻辑，把时区偏移统一换算成分钟再拼字符串，例如 +05:30 → 330，然后生成
INTERVAL '330 minutes' - 检查
pg_settings里的intervalstyle，设为'postgres'可减少部分解析歧义，但不解决根本问题 - 如果用的是自定义视图或函数，确保里面所有
INTERVAL字面量都符合 PostgreSQL 语法，别抄 MySQL 写法
最易被忽略的一点：时区转换不是加减固定小时数，而是按真实时区规则（含夏令时）做语义转换。哪怕你硬写 created_at + INTERVAL '8 hours'，遇到夏令时切换日也可能错 1 小时。务必用数据库原生的时区转换函数，而不是数学运算模拟。
