datediff 按单位统计时间边界跨越次数而非简单相减，如 day 单位跨午夜即计1；避免用于“自然天数”计算，应加1；跨库需用 timestampdiff（mysql）或 age（postgresql）；跨夏令时须转utc；参数类型不一致或字符串字面量会损失精度且影响索引。
SQL Server 的 DATEDIFF 函数怎么用才不偏移一天？
DATEDIFF 不是“两个日期相减”，而是“按指定单位统计边界跨越次数”。比如 DATEDIFF(day, '2024-01-01 23:59:59', '2024-01-02 00:00:01') 返回 1，不是 0——因为跨过了午夜这个 day 边界。这点常被误认为“计算不准”。
- 单位越小（如
second），结果越接近真实差值；单位越大（如month），越依赖日历规则（比如DATEDIFF(month, '2023-01-31', '2023-02-28')返回1，哪怕 2 月没 31 号） - 不要用
day计算“存活天数”类业务：用户注册于'2024-03-15'，今天是'2024-03-15'，DATEDIFF(day, 注册日, GETDATE())是0，但很多人期望是1 - 若需包含起始日的“自然天数”，改用
DATEDIFF(day, 开始日, 结束日) + 1
MySQL 和 PostgreSQL 里没有 DATEDIFF，怎么等价替换？
MySQL 有同名函数但行为不同：DATEDIFF(end, start) 固定返回天数差（只取日期部分，忽略时间），且结果是 end - start 的整数天，不跨边界计数。PostgreSQL 则压根没这个函数。
- MySQL：直接用
DATEDIFF('2024-03-20', '2024-03-15')→5；但DATEDIFF('2024-03-20 10:00', '2024-03-15 15:00')仍是5（时间被截断） - PostgreSQL：用
(end_time - start_time)得到 interval，再提取字段，例如(end_ts - start_ts) * INTERVAL '1 day'不行，要写EXTRACT(day FROM (end_ts - start_ts))或直接end_ts - start_ts（返回 interval，可参与运算） - 跨数据库移植时，别硬套 SQL Server 写法；统一用
TIMESTAMPDIFF（MySQL）或AGE()（PostgreSQL）更稳妥
为什么 DATEDIFF(hour, ...) 在跨夏令时地区会出错？
SQL Server 的 DATEDIFF 按本地时区的物理小时计算，不考虑夏令时跳变。比如某地 3 月10日凌晨2点拨快1小时，那么 DATEDIFF(hour, '2024-03-10 01:00', '2024-03-10 03:00') 返回 1（实际只过了1小时，但钟面从1→3跳了），而你可能预期是 2。
- 关键点：它算的是“时钟读数差”，不是“真实经过时间”
- 涉及跨时区或夏令时的场景（如航班、日志分析），必须先把时间转成 UTC 再计算：
DATEDIFF(second, SWITCHOFFSET(start_dt, '+00:00'), SWITCHOFFSET(end_dt, '+00:00')) - 如果源数据已是 UTC，就别用
GETDATE()做对比——它返回本地时区，容易引入偏差
用 DATEDIFF 做分组统计时，哪些隐式转换会悄悄吃掉精度？
当传入字符串参数，比如 DATEDIFF(day, '2024-03-15', col_datetime)，SQL Server 会把字符串转成 datetime 类型（精度只到 3.33ms），而 datetime2 列可能存纳秒级时间。这种转换会导致边界判断偏移。
- 始终确保两个参数类型一致：都用
datetime2，或都显式CAST(... AS datetime2) - 避免字符串字面量：用
DATEADD(day, -7, GETDATE())比'2024-03-10'更可靠 - 在 WHERE 中用
DATEDIFF作条件（如DATEDIFF(day, create_time, GETDATE()) > 30）会阻止索引使用——改写为create_time
真实业务里最麻烦的不是语法，是搞清你要的到底是“日历差”、“物理间隔”还是“用户感知天数”。选错单位或忽略时区/类型隐式转换，结果可能差几个小时甚至一整天。
