直接写'2023-12-01'因数据库隐式转换规则不同导致结果不一致，正确做法是显式指定UTC时间边界或使用毫秒级UTC时间戳。
WHERE 条件里直接写 '2023-12-01' 会出错
字符串字面量如 '2023-12-01' 在不同数据库中隐式转换规则完全不同：Oracle 依赖 NLS_DATE_FORMAT，MySQL 可能补 00:00:00，PostgreSQL 则按 date 类型截断。结果是同一行 SQL，在 Oracle 里漏掉当天 18:00 后的数据，在 PostgreSQL 里却全量返回。
正确做法是显式指定时间边界：
- 用
BETWEEN '2023-12-01 00:00:00' AND '2023-12-01 23:59:59'（注意毫秒精度问题） - 更推荐
created_at >= '2023-12-01' AND created_at ，避免末尾秒级截断误差 - 若字段含毫秒（如
DATETIME(3)），必须写成'2023-12-01 00:00:00.000'和'2023-12-02 00:00:00.000'
过滤前必须统一转为 UTC 时间
如果 created_at 字段存的是纽约本地时间（US/Eastern），而你用 WHERE created_at > '2023-12-01' 过滤，那这个 “2023-12-01” 是按哪个时区解释的？没人知道——数据库不会猜，它只会按当前会话时区或字段类型硬解析。
真正安全的做法是把比较逻辑拉到 UTC 层面：
- MySQL：
WHERE CONVERT_TZ(created_at, 'US/Eastern', '+00:00') > '2023-12-01 00:00:00' - PostgreSQL：
WHERE created_at AT TIME ZONE 'US/Eastern' AT TIME ZONE 'UTC' > '2023-12-01 00:00:00' - BigQuery：
WHERE DATETIME(created_at, "US/Eastern") > DATETIME('2023-12-01', "UTC")
但注意：这些函数调用会让索引失效。生产环境应提前物化 UTC 列，或在应用层完成转换后传入参数。
DATETIME vs TIMESTAMP：选错类型等于埋雷
DATETIME 是快照，TIMESTAMP 是带自动转换的 UTC 容器——它们行为差异极大：
-
TIMESTAMP写入时自动转 UTC，读取时按会话time_zone转回；一旦 DBA 改了全局time_zone，所有历史查询结果都会偏移 -
DATETIME从不自动转换，但也不告诉你它属于哪个时区；你存的是东京时间，它就当东京时间存，查出来还是东京时间，哪怕你人在纽约 - 跨时区项目强烈建议用
BIGINT存毫秒级 UTC 时间戳（如1732842000000），彻底绕开数据库时区逻辑
夏令时切换日的 WHERE 条件要特别小心
像 '2026-03-09 02:30:00' 在 US/Eastern 时区根本不存在——那天凌晨 2:00 直接跳到 3:00，中间空出一小时。如果你在 WHERE 中写了这个时间点，MySQL 或 PostgreSQL 可能静默返回空结果，而不是报错。
更危险的是“重复时间”：11 月第一个周日凌晨 1:30 会出现两次（EDT → EST）。此时 CONVERT_TZ() 或 AT TIME ZONE 的行为取决于底层 IANA 时区表是否更新、数据库版本是否支持歧义消解。
应对策略：
- 永远不要在 WHERE 中硬写带时区的本地时间字符串
- 所有业务时间过滤，统一换算成 UTC 时间点再比较
- 对关键报表，加一层校验：比如检查某天是否有数据落在
02:00–03:00区间，若有则触发告警
最麻烦的不是写错 SQL，而是错误在夏令时切换后才暴露——等你发现时，数据已经错失三天。
