mysql的datediff函数只比较日期部分，自动截断datetime的时间信息；sql server需指定datepart（如day）且结果含方向性；postgresql无datediff，用date相减或extract；跨数据库不兼容，需按方言适配。
MySQL里DATEDIFF只接受DATE类型，传DATETIME会截断时间部分
MySQL的DATEDIFF函数严格要求两个参数都是DATE类型，如果传入DATETIME或TIMESTAMP，它会自动忽略时分秒，只比较日期部分。这意味着DATEDIFF('2024-01-01 23:59:59', '2024-01-02 00:00:01')结果是-1，而不是你可能预期的0。
常见错误是直接拿NOW()或带时间的字段参与计算，导致结果偏差。稳妥做法是先用DATE()显式转换：
SELECT DATEDIFF(DATE('2024-01-01 15:30:00'), DATE('2024-01-03 09:15:00'));
- 如果字段本身就是
DATE类型（如order_date），可直接用DATEDIFF(date1, date2) - 若字段是
DATETIME（如created_at），务必套一层DATE(created_at) - 注意参数顺序：第一个减第二个，
DATEDIFF(a, b)= a − b（天数）
SQL Server的DATEDIFF必须指定datepart，且结果含方向性
SQL Server的DATEDIFF语法是DATEDIFF(datepart, startdate, enddate)，不能省略datepart。要算天数差，必须写day（不是days，也不是d——虽然d在某些版本兼容，但不推荐）。
它返回的是“跨越了多少个指定单位边界”，不是简单的日历差。例如DATEDIFF(day, '2024-01-01 23:59:59', '2024-01-02 00:00:01')结果是1，因为跨过了午夜线。
- 必须用
day作为第一个参数，写成DATEDIFF(day, a, b) - 结果可正可负，取决于
startdate和enddate大小关系 - 如果只需要绝对值，得手动套
ABS()：ABS(DATEDIFF(day, a, b))
PostgreSQL没有DATEDIFF，用减法运算符更直观
PostgreSQL不提供DATEDIFF函数，而是直接支持DATE或TIMESTAMP相减，结果是INTERVAL类型。要得到整数天数，需用EXTRACT或AGE配合转换。
针对嵌入式/固件项目的专家代码审查，采用双模型交叉审查（Claude + Codex via ACP），检测内存安全、中断危险、RTOS陷阱...
最常用也最安全的方式是：两个DATE相减得整数天数；两个TIMESTAMP相减后用EXTRACT(DAY FROM ...)取天数部分——但要注意这仅取“日”字段，不累计小时换算。
SELECT ('2024-01-05'::DATE - '2024-01-01'::DATE) AS days_diff;
- 纯日期相减（
DATE - DATE）直接返回整数，最简洁可靠 - 若含时间，建议先转
DATE再减，避免EXTRACT对INTERVAL的歧义处理 -
AGE(end, start)返回INTERVAL，适合展示“X年Y月Z天”，不适合数值计算
跨数据库写法不通用，别硬套一个函数名到处用
看到DATEDIFF就默认它是“标准SQL函数”是个典型误区。它在MySQL、SQL Server、Oracle中行为不同，PostgreSQL干脆没有。硬把MySQL写法复制到SQL Server会报错，反过来也可能因截断逻辑导致数据偏差。
实际项目里，尤其涉及多数据库兼容或ORM映射时，优先考虑抽象层封装，或在应用层做日期差计算（如Python用(date2 - date1).days）。数据库内计算只在必要时做，且必须按目标方言校验。
最容易被忽略的是时区和夏令时影响——哪怕同是DATEDIFF(day, ...)，在跨时区时间戳上，SQL Server和PostgreSQL的处理逻辑也不一致。真要精确到小时级差异，别依赖day单位，改用timestampdiff（MySQL）或DATEDIFF(SECOND, ...)再除以86400。
