聚合统计必须明确“今日”所属时区，CURDATE()或DATE(NOW())依赖服务器本地时区，易致跨日错误；应由应用层传入目标时区的日期边界，数据库仅做范围过滤。
聚合统计必须明确“今日”属于哪个时区
用 CURDATE() 或 DATE(NOW()) 做“今日订单量”这类聚合，本质是把服务器本地时区当天当标准——但服务器在新加坡，用户在旧金山，同一秒可能已是“明日”。结果就是：纽约用户凌晨下单，被算进“明天”，而实际业务要求按用户本地日历归类。
真正安全的做法是：由应用层传入目标时区下的日期边界（如 '2026-10-02' 和 '2026-10-03'），数据库只做范围过滤，不参与时区判定。
- 不要写
WHERE DATE(created_at) = CURDATE()——created_at若为TIMESTAMP类型，DATE()会先按会话时区转成日期，再截断，极易跨日 - 改写为
WHERE created_at >= '2026-10-02 00:00:00' AND created_at ，且该时间字符串必须是目标时区下解析后的 UTC 时间（例如用户在东京，“今日”对应 UTC 是 <code>'2026-10-01 15:00:00'到'2026-10-02 15:00:00'） - 若必须在 SQL 中动态生成目标时区日期，MySQL 可用
CONVERT_TZ(UTC_TIMESTAMP(), '+00:00', 'Asia/Tokyo')先转再截，但前提是时区表已加载且函数可用；PostgreSQL 更稳：(NOW() AT TIME ZONE 'Asia/Tokyo')::date
MySQL中用CONVERT_TZ做聚合前必须检查时区表
CONVERT_TZ(NOW(), '+00:00', 'Asia/Shanghai') 返回 NULL 不是语法错，而是 MySQL 根本不认识 Asia/Shanghai —— 它的时区名来自内置表 mysql.time_zone_name，默认为空。
验证方式：SELECT COUNT(*) FROM mysql.time_zone_name;，结果为 0 就得手动加载。
- Linux 下执行：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql - macOS 路径通常是
/var/db/timezones/zoneinfo - Windows 需下载官方时区 SQL 文件导入
- 加载后确认名称匹配：
SELECT Name FROM mysql.time_zone_name WHERE Name LIKE '%Shanghai%';，返回值必须是Asia/Shanghai，不能是CST或China Standard Time
PostgreSQL中AT TIME ZONE对无时区时间的隐式解释风险
写 SELECT '2026-10-02 10:00:00'::timestamp AT TIME ZONE 'Asia/Shanghai';，PostgreSQL 会把字面量按当前会话时区解释，再转目标时区。如果会话时区是 UTC，它就认为输入是 UTC 时间；如果会话是 America/New_York，它就当成纽约时间——结果完全不可控。
正确做法是显式标注源时区语义：
- 若原始时间本就是北京时间，应先转成带时区类型：
'2026-10-02 10:00:00'::timestamptz AT TIME ZONE 'Asia/Shanghai'（注意双冒号后是timestamptz） - 更稳妥的是让应用传入已带时区的时间字符串，如
'2026-10-02 10:00:00+08'，直接 cast 为timestamptz，避免任何隐式假设 - 聚合时优先用
timezone('Asia/Shanghai', created_at)函数，它比AT TIME ZONE更明确地表达“把created_at按上海时区解释”
SQL Server里别用GETDATE()推导用户本地日期
GETDATE() 返回服务器本地时间，SYSDATETIMEOFFSET() 返回服务器时区偏移——两者都和用户无关。用它们算“用户今日活跃数”，等于把全球用户强行塞进一个时区日历。
安全路径只有两条：
- 应用层计算好目标时区的日期范围（如用户时区下的
'2026-10-02'），作为参数传入存储过程，SQL 只做BETWEEN过滤 - 若必须在 SQL 内转换，参数必须含源时区名（如
@user_tz VARCHAR(50)），再用TODATETIMEOFFSET(@input_time, @user_tz) AT TIME ZONE 'UTC' AT TIME ZONE @target_tz链式转换；注意 SQL Server 用 Windows 时区名，Asia/Shanghai要写成China Standard Time - 绝对不要用
DATEADD(hour, 8, GETDATE())这类硬编码偏移——夏令时、历史政策变更（如哈萨克斯坦2024年取消夏令时）会让这种写法突然失效
CST）做不到。 
