必须先将时间字段统一转为业务时区再截取自然日，而非直接group by原始时间字段；mysql需建生成列提升性能，postgresql注意at time zone操作顺序，sql server须用todatetimeoffset显式标注偏移。
直接用原始时间字段 GROUP BY 会把跨时区的同一天数据切散，或把不同自然日的数据挤进同组——必须先转时区再截日期，且不能在 GROUP BY 里实时调函数。
MySQL 中用 CONVERT_TZ() 转时区再分组
核心是两步：先统一转业务时区（如 'Asia/Shanghai'），再用 DATE() 截取自然日。写成 GROUP BY DATE(CONVERT_TZ(created_at, '+00:00', 'Asia/Shanghai')) 看似可行，但每次查询都实时计算，无法走索引。
-
created_at必须是DATETIME或TIMESTAMP类型；如果是字符串，得先用STR_TO_DATE(created_at, '%Y-%m-%d %H:%i:%s')转型，否则CONVERT_TZ()静默返回NULL - 更优做法是建生成列：
ALTER TABLE orders ADD COLUMN biz_date DATE AS (DATE(CONVERT_TZ(created_at, '+00:00', 'Asia/Shanghai'))) STORED，然后GROUP BY biz_date - 确认时区表已加载：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql，否则CONVERT_TZ()返回NULL
PostgreSQL 中用 AT TIME ZONE 对齐再截断
PostgreSQL 的 AT TIME ZONE 是后缀操作符，不是链式函数。它默认把输入值当成本地时间解释，所以直接写 created_at AT TIME ZONE 'Asia/Shanghai' 得到的是 UTC 时间戳，不是你想要的东八区时间。
- 正确写法是：
(created_at AT TIME ZONE 'UTC') AT TIME ZONE 'Asia/Shanghai'，前提是created_at存的是 UTC（TIMESTAMP WITHOUT TIME ZONE） - 若字段是
TIMESTAMPTZ，则created_at AT TIME ZONE 'Asia/Shanghai'可直接得到带时区的本地时间，再用DATE()或DATE_TRUNC('day', ...)截取 - 按自然周分组（周一为起点）：
DATE_TRUNC('week', created_at AT TIME ZONE 'Asia/Shanghai') + INTERVAL '1 day'
SQL Server 中必须用 TODATETIMEOFFSET() 显式打标
SQL Server 的 AT TIME ZONE 只接受 DATETIMEOFFSET 类型。对 DATETIME 或 DATETIME2 直接调用会静默转成无偏移值，再转换时因源时区不明，结果不可靠。
- 错误写法：
GETDATE() AT TIME ZONE 'China Standard Time'→ 返回NULL - 正确路径：先用
TODATETIMEOFFSET(@local_time, '+08:00')或TODATETIMEOFFSET(@local_time, 'China Standard Time')构造带偏移值，再链式调用AT TIME ZONE 'UTC' - 注意：SQL Server 只认 Windows 时区名（如
'China Standard Time'），不支持 IANA 名（如'Asia/Shanghai'） - 存储过程参数建议接收
@source_offset VARCHAR(6)（如'+08:00'）而非时区名，避免映射歧义
真正容易被忽略的不是语法，而是字段类型和写入逻辑：如果 created_at 是 DATETIME 类型且混存了不同时区的时间字符串，再怎么转函数也没用——源头没统一，下游所有聚合都会漂移。
