做计费、做报表、做工单系统的兄弟大概率都撞过同一个需求：给两个时间点，把中间相隔的天数算出来。听起来就是一句话的事，但真落到 DB2 上，你会发现光是“天数”这两个字就有好几种解释——是掐头算还是去尾算？只看日期还是带时分秒？跨月跨年、闰年二月、夏令时切换要不要管？我这些年做账期结算、工单时效统计、会员有效期核算这类活儿，被这个需求反复折腾过好几轮，也见过不少同事写出看着能跑、上线后数字对不上的 SQL。这篇就把 DB2 里“根据开始和结束时间算相隔天数”这件事从头到尾捋一遍：几种写法各自的原理、精度、性能代价，什么场景该用哪个，以及那些文档里不会写、只有踩过才知道的坑。不管你是刚接触 DB2 的 SQL 新手，还是已经写了几年报表的老手，应该都能从里面找到能直接抄走的写法。
1. 先把“天数”这个词掰开：口径不定，SQL 一定写错
1.1 四种常见的“天数”口径，先选再写
我见过最典型的翻车现场是这样：产品经理说“算一下相隔天数”，开发吭哧吭哧写了个函数，测试拿两条数据一对，差了1天，然后开始互相甩锅。根子不在 SQL，而在一开始没人把口径定义清楚。在 DB2 里写这句 SQL 之前，至少要在心里回答四个问题。
第一个问题是边界怎么算。1月1日到1月2日，是 1 天还是 2 天？酒店行业通常算 2 天（入住当天和离店当天都占），账期结算通常算 1 天（1月1日产生的应收，1月2日到期）。这就是所谓“含头含尾”和“含头不含尾”的区别，落到公式上就是最后要不要+1。
第二个问题是精度到哪一级。有的场景只要整天数，比如“合同签了多久”；有的场景要小数天，比如“平均故障恢复时长 2.35 天”；还有的场景要向上取整，比如“超时不足一天按一天计费”。这三种口径在 DB2 里对应完全不同的函数组合，混用必出错。
第三个问题是时分秒怎么处理。开始时间是2024-03-01 18:30:00，结束时间是2024-03-02 09:00:00，这算 1 天还是 0 天？按自然日算就是 1 天，按时长折算就是 0.6 天。做 SLA 统计的时候这两种算法给出的报表能差出一倍，所以必须先跟业务方确认清楚。
第四个问题是时区和工作日历。系统里存的是带时区的时间戳，还是本地时间？中间跨不跨周末和法定节假日？这两个问题一旦牵扯进来，纯靠一个内置函数就解决不了了，得配合日历表来做。
我的建议很朴素：在 SQL 注释里把口径写清楚。别嫌麻烦，-- 含头不含尾，向上取整到天这一行注释，能省掉你半年后回来改代码时的半小时回忆。
1.2 为什么两个日期直接相减得到的不是天数
很多人第一反应是end_date - start_date，因为不少数据库确实是这么干的。在 DB2 里这么写不会报错，但它返回的根本不是天数，而是一个DECIMAL(8,0)类型的“日期持续时间”，格式是YYYYMMDD拼出来的数字。举个具体的例子：
SELECT DATE('2024-03-05') - DATE('2024-02-01') FROM SYSIBM.SYSDUMMY1;结果会得到104。这玩意儿读作“0 年 1 月 4 天”，不是 104 天，也不是 1 天零 4 小时。真实相隔天数是 33 天。如果你随手写了个MOD(结果, 100)想取天数，拿到的是 4，跟 33 差着十万八千里。
更坑的是这个错误有时候看起来是对的。同月内相减，比如2024-03-05减2024-03-01，结果是4，恰好等于真实天数差，测两条数据就以为没问题了，一上生产跨月就炸。所以这条路径我通常直接在评审时掐死：
注意：
DATE - DATE在 DB2 里返回的是 DECIMAL 形式的年月日组合值，绝不是天数。哪怕你只要同月内的差值，也别用，养成坏习惯迟早出事。
真正靠得住的思路只有两条：要么把日期换算成一个连续的整数轴（DAYS()就是这个轴），要么用专门的时间差函数（TIMESTAMPDIFF）。下面逐个说。
2. DB2 日期时间类型与可用函数盘点
2.1 DATE、TIMESTAMP、TIME 三者的边界别搞混
DB2 里跟这个需求相关的类型主要有三个，很多人写错 SQL 是因为压根没分清它们。
DATE只存年月日，长度 10 字节，内部表示是 4 字节的整数（年月日各占几位）。它没有时分秒的概念，所以你拿它算天数天然就是“自然日口径”。
TIMESTAMP存年月日时分秒加微秒，默认精度 6，TIMESTAMP(0)到TIMESTAMP(12)可以指定精度。它才是业务表里最常见的那种“创建时间”“更新时间”。
TIME只存时分秒，日常几乎用不到单独存它，因为脱离日期的时间没有跨度意义。
类型之间互转的写法要背下来，别靠隐式转换：
SELECT DATE(CURRENT TIMESTAMP) AS 只留日期, TIMESTAMP(DATE('2024-03-01')) AS 日期补零点到时间戳, CAST('2024-03-01' AS DATE) AS 字符串转日期 FROM SYSIBM.SYSDUMMY1;这里有个必须提醒的点：DATE(某列)这种写法会把时分秒直接砍掉，不是四舍五入。2024-03-01 23:59:59转成 DATE 就是2024-03-01。如果你的业务口径是“超过当天中午就算第二天”，那就得自己加逻辑，别指望类型转换帮你做。
还有日期字面量的格式问题。DB2 解析字符串日期时会参考当前的日期时间格式设置（ISO、USA、EUR、JIS 等），'03/01/2024'到底是 3月1日还是 1月3日，取决于这个设置。所以我在任何生产 SQL 里都强制写DATE('2024-03-01')这种 ISO 格式加显式函数，绝不裸写字符串让它自己猜。
2.2 DAYS()：最朴素也最稳的那把锤子
DAYS()这个函数值得单独拎出来讲，因为它是我在这个需求里用得最多、出问题最少的一个。
它的逻辑极其简单：接收一个日期或时间戳，返回一个整数，表示从公元 1 年 1 月 1 日算起的第几天。DAYS('0001-01-01')返回 1，往后每一天加 1。因为这是一条连续的整数轴，两个DAYS()相减，得到的必然是精确的自然日间隔，不受月份天数、闰年、跨年影响。
SELECT DAYS(DATE('2024-03-01')) - DAYS(DATE('2024-02-01')) AS 闰年二月, DAYS(DATE('2025-01-01')) - DAYS(DATE('2024-12-31')) AS 跨年一天 FROM SYSIBM.SYSDUMMY1;第一行算出 29（2024 年是闰年，2月有 29 天），第二行算出 1。两个结果都符合直觉，这就是连续整数轴的好处——它把所有“这个月有几天”的麻烦事都替你消化掉了。
DAYS()传TIMESTAMP也是可以的，等价于先DATE()掉时分秒再算。所以DAYS(create_time)和DAYS(DATE(create_time))结果一样。但我在代码里倾向于显式写DATE()，原因很简单：让读代码的人一眼看出我做了截断，而不是怀疑我在按小时算。
提示：
DAYS()极少数情况下会遇到参数为 NULL 返回 NULL，做报表聚合时记得套COALESCE，否则整行的平均值会被 NULL 吃掉。
2.3 TIMESTAMPDIFF：能算，但要先知道它的脾气
TIMESTAMPDIFF是另一个常用选择，它的第一个参数是个整数间隔代码，不是字符串。这一点劝退过不少人，因为习惯其他数据库写法的人会本能地写TIMESTAMPDIFF('DAY', ...)。
DB2 的间隔代码是位值：1 表示秒的小数部分，2 表示秒，4 表示分，8 表示小时，16 表示天，32 表示周，64 表示月，128 表示季度，256 表示年。所以算天数要用 16，算小时用 8。
-- 老式两参数写法，先做时间戳减法得到持续时间字符串 SELECT TIMESTAMPDIFF(16, CHAR(TIMESTAMP('2024-03-01-12.00.00') - TIMESTAMP('2024-02-28-00.00.00'))) FROM SYSIBM.SYSDUMMY1; -- 较新版本支持的三参数写法 SELECT TIMESTAMPDIFF(16, TIMESTAMP('2024-02-28-00.00.00'), TIMESTAMP('2024-03-01-12.00.00')) FROM SYSIBM.SYSDUMMY1;两段都返回 2。注意：真实间隔是 2 天 12 小时，它返回 2 而不是 2.5——TIMESTAMPDIFF是截断取整，不是四舍五入。想要 2.5 或者 3，得自己在外面套ROUND或者CEILING。
它的第二个脾气是结果是近似值。DB2 内部是把两端时间换算成秒数再除以单位长度来算的，所以理论上存在因边界调整导致偏差一天的可能。日常业务里这个误差极少触发，但如果你在算金融计息、法律时效这种一差一天就要出事的场景，我还是建议用DAYS()那条路。
第三个脾气是版本和平台差异。三参数形式在老版本上不一定认，DB2 for i、DB2 for z/OS跟DB2 LUW的支持情况也不完全一致。跨平台的项目里，DAYS()的兼容性明显更好。我的做法是：能用DAYS()解决的，不用TIMESTAMPDIFF；只有当精度必须细到小时、分钟，或者需要跨到月、年维度时才请它出场。
2.4 MIDNIGHT_SECONDS：想要小数天的必备搭档
如果业务要“2.35 天”这种小数精度，光靠DAYS()拿不到。这时候MIDNIGHT_SECONDS()就派上用场了。它接收一个时间戳，返回到当天零点为止的秒数，取值 0 到 86400。
组合出来的公式是这样：
SELECT (DAYS(DATE(end_ts)) - DAYS(DATE(start_ts))) + (MIDNIGHT_SECONDS(end_ts) - MIDNIGHT_SECONDS(start_ts)) / 86400.0 AS 精确天数 FROM 某业务表;拆开看就很好理解：前面一段算整天的差，后面一段把两端“当天已经过去的秒数”相减再折算成天。比如开始是 18:00（64800 秒），结束是次日 09:00（32400 秒），整天差是 1，秒数差是32400 - 64800 = -32400，折算成天是 -0.375，最终 0.625 天。跟手算的 15 小时对得上。
86400.0后面那个.0千万别省。在 DB2 里整数除整数会走整数除法，3600 / 86400直接给你 0，这个坑我见过不止一个人踩。带上小数点强制走浮点，或者在分子上套DOUBLE()都行。
3. 四种写法逐一对拍与选型
3.1 写法一：DAYS 相减法，日常首选
完整形态长这样，我一般封装成一个可以直接粘的口径：
-- 含头不含尾，自然日口径 SELECT DAYS(DATE(end_time)) - DAYS(DATE(start_time)) AS 相隔天数 FROM 某业务表; -- 含头含尾，两边都算 SELECT DAYS(DATE(end_time)) - DAYS(DATE(start_time)) + 1 AS 占用天数 FROM 某业务表;优势非常明确：结果精确到整数天，没有近似误差；不依赖版本特性；代码自解释，谁读都懂。缺点是不支持小数天，以及如果列本身是时间戳，DATE()包裹会损失时分秒信息。
适用场景我总结了几类：账期天数、合同持续天数、会员有效天数、请假天数统计。这些业务要的就是自然日口径，多一分少一分都不行。
3.2 写法二：CAST 后再算，本质相同但更显式
SELECT DAYS(CAST(end_time AS DATE)) - DAYS(CAST(start_time AS DATE)) AS 相隔天数 FROM 某业务表;这跟写法一没有性能差异，也不会更快或更慢，纯粹是可读性取向。CAST的优势在于类型转换意图更明确，特别是在列本身是VARCHAR存日期字符串的烂设计里，CAST比DATE()更能提醒后来人“这里做过一次类型转换，注意格式”。
顺带说一句，如果列是字符串存的，先跑一句体检：
SELECT COUNT(*) AS 脏数据条数 FROM 某业务表 WHERE start_time IS NOT NULL AND NOT REGEXP_LIKE(start_time, '^[0-9]{4}-[0-9]{2}-[0-9]{2}');REGEXP_LIKE在较新的 DB2 版本可用，老版本用TRANSLATE那一套比较麻烦，实在不行就直接CAST一遍看会不会抛错。把脏数据清干净，比在 SQL 里写一堆防御逻辑划算得多。
3.3 写法三：时间戳直接相减再解析，不推荐但要知道
SELECT TIMESTAMP('2024-03-05-10.30.00') - TIMESTAMP('2024-02-01-08.00.00') FROM SYSIBM.SYSDUMMY1;结果是DECIMAL(14,0)，形如00000104023000，读作 0 年 1 月 4 天 2 小时 30 分。这个格式跟前面DATE - DATE是一个套路，只是精度扩展到了时分秒。
能用吗？能，但你要自己解析出年月日时分秒再折算，代码丑陋且容易错。唯一的合理用途是调试时看一眼真实间隔，判断数据是不是反了。生产代码里别用。
3.4 写法四：TIMESTAMPDIFF 组合，精细场景才上
-- 向上取整到天，适用于"不足一天按一天计费" SELECT CEILING(TIMESTAMPDIFF(2, CHAR(end_time - start_time)) / 86400.0) AS 计费天数 FROM 某业务表;这段先算出总秒数（代码 2 是秒），除以 86400 换成天，再CEILING向上取整。好处是精度完全可控，坏处是可读性差、依赖版本、还引入了一次字符串转换。
3.5 选型对照表
| 写法 | 精度 | 是否受版本影响 | 性能 | 推荐场景 |
|---|---|---|---|---|
DAYS(end) - DAYS(start) | 整数天 | 基本无 | 好 | 账期、合同、请假等自然日口径 |
DAYS(CAST(..))组合 | 整数天 | 基本无 | 好 | 字符串列转日期、需要显式声明 |
| 时间戳直接相减 | 年月日时分秒 | 无 | 好 | 仅调试排查 |
TIMESTAMPDIFF(16, ...) | 整数天（截断） | 有 | 中 | 需要按小时差推导天 |
TIMESTAMPDIFF(2, ...)/86400.0 | 小数天 | 有 | 中 | 计费、SLA、平均时长 |
DAYS + MIDNIGHT_SECONDS | 小数天 | 基本无 | 好 | 需要小数天且想避开版本差异 |
这张表我贴在自己的笔记里，每次写新 SQL 前扫一眼，基本不会再选错路。
4. 落到业务里的完整实操
4.1 建表与造一批能覆盖边界的测试数据
光看语法没感觉，直接建个模拟表跑起来。为了把闰年、跨月、跨年、时间部分这些边界全踩到，测试数据要有针对性：
CREATE TABLE 模拟账期表 ( 单据号 VARCHAR(20) NOT NULL, 开始时间 TIMESTAMP NOT NULL, 结束时间 TIMESTAMP, 状态 VARCHAR(10) ); INSERT INTO 模拟账期表 VALUES ('A001', TIMESTAMP('2024-02-01-00.00.00'), TIMESTAMP('2024-03-01-00.00.00'), '结清'), ('A002', TIMESTAMP('2024-02-01-08.30.00'), TIMESTAMP('2024-03-01-17.45.00'), '结清'), ('A003', TIMESTAMP('2024-12-31-23.00.00'), TIMESTAMP('2025-01-01-01.00.00'), '结清'), ('A004', TIMESTAMP('2024-03-01-09.00.00'), NULL, '在途'), ('A005', TIMESTAMP('2024-03-02-20.00.00'), TIMESTAMP('2024-03-01-20.00.00'), '异常');A001 是标准的整月，DAYS差是 29。A002 首尾都带时间，DAYS差还是 29，但真实时长不到 29 天。A003 跨年，只差 2 小时。A004 是空值，考验NULL处理。A005 是反的，结束早于开始，专门用来验证业务上要不要拦截。
这批数据看着简单，但每次我把新写的天数 SQL 往上跑一遍，八成能抓出问题。
4.2 账期天数：最常写的那个查询
按“含头不含尾”的自然日口径：
SELECT 单据号, DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) AS 账期天数 FROM 模拟账期表 WHERE 状态 = '结清';跑出来 A001 是 29，A002 是 29，A003 是 1。A002 虽然两头都带时间，但因为做了截断，结果跟整月一样——这正好对应“自然日口径”的定义，符合预期。
如果业务说“首尾都算”，就改成：
SELECT 单据号, DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) + 1 AS 占用天数 FROM 模拟账期表 WHERE 状态 = '结清';注意：
+1加不加，一定写进需求文档和 SQL 注释。我见过一个团队因为这块没对齐，财务口径和系统口径各算各的，季度对账时差了整整一个月的量。
对于 A004 这种在途单据，结束时间为NULL，减法结果整个变成NULL，聚合时会被忽略。如果业务要求“在途按今天算”，得用COALESCE：
SELECT 单据号, DAYS(DATE(COALESCE(结束时间, CURRENT TIMESTAMP))) - DAYS(DATE(开始时间)) AS 已挂天数 FROM 模拟账期表;这个写法在工单时效报表里出现频率极高，顺手记一下。
4.3 小时级精度折算成天，向上取整的完整实现
计费类场景经常是“不足一天按一天收”。这时候最稳的写法是走MIDNIGHT_SECONDS，避开TIMESTAMPDIFF的版本差异：
SELECT 单据号, CEILING( (DAYS(DATE(结束时间)) - DAYS(DATE(开始时间))) + (MIDNIGHT_SECONDS(结束时间) - MIDNIGHT_SECONDS(开始时间)) / 86400.0 ) AS 计费天数 FROM 模拟账期表 WHERE 状态 = '结清' AND 结束时间 IS NOT NULL;拿 A002 手算验证一下：开始2024-02-01 08:30，结束2024-03-01 17:45。整天差 29，MIDNIGHT_SECONDS分别是30600和63900，差33300秒，约0.385天，合计29.385，CEILING上去是 30 天。业务上确实应该按 30 天收，因为跨了 30 个自然日的不同时刻，逻辑对得上。
如果是“按完整 24 小时为一个单位，余数不足不计”的口径，把CEILING换成FLOOR就行。这两个函数很容易记混，我一般会写个小测试：
SELECT CEILING(29.1), FLOOR(29.1), CEILING(29.9), FLOOR(29.9) FROM SYSIBM.SYSDUMMY1;跑一次就再也不会搞错了。
4.4 报表里的聚合：按天数分档统计
天数算出来之后，下一步基本都是分档。比如统计账期分布：
SELECT CASE WHEN DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) <= 30 THEN '30天以内' WHEN DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) <= 90 THEN '31到90天' WHEN DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) <= 180 THEN '91到180天' ELSE '180天以上' END AS 账期区间, COUNT(*) AS 单据数 FROM 模拟账期表 WHERE 状态 = '结清' GROUP BY CASE WHEN DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) <= 30 THEN '30天以内' WHEN DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) <= 90 THEN '31到90天' WHEN DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) <= 180 THEN '91到180天' ELSE '180天以上' END ORDER BY 单据数 DESC;这段代码有点长，关键是GROUP BY里要把整个CASE原样再写一遍，不能只写别名。想省事可以用WITH先算一层：
WITH 明细 AS ( SELECT DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) AS 天数 FROM 模拟账期表 WHERE 状态 = '结清' AND 结束时间 IS NOT NULL ) SELECT CASE WHEN 天数 <= 30 THEN '30天以内' WHEN 天数 <= 90 THEN '31到90天' WHEN 天数 <= 180 THEN '91到180天' ELSE '180天以上' END AS 账期区间, COUNT(*) AS 单据数 FROM 明细 GROUP BY 1 ORDER BY 1;GROUP BY 1这种按序号引用的写法在 DB2 上是支持的，可读性见仁见智，但确实省了一大坨重复代码。
4.5 工作日天数：内置函数搞不定，得靠日历表
前面所有写法算的都是自然日。业务一旦说“按工作日算”，内置函数就全部失灵了，因为 DB2 不知道你们公司哪几天放假。
现实中我见过两种落地方式。第一种是建一张工作日历表，把每天的日期和是否工作日打上标记，然后关联统计：
SELECT t.单据号, COUNT(c.日历日期) AS 工作日天数 FROM 模拟账期表 t JOIN 工作日历表 c ON c.日历日期 > DATE(t.开始时间) AND c.日历日期 <= DATE(t.结束时间) AND c.是否工作日 = 1 WHERE t.状态 = '结清' GROUP BY t.单据号;注意这里用的是>和<=，对应“含头不含尾”。想改成含头含尾就把左边改成>=。日历表的好处是节假日调整只用改数据，不用改 SQL，每年年底更新一次就行。
第二种是纯算法，用(天数 / 7) * 5 + 余数部分粗算，再减去已知节假日。这种方法我只在没法建表的历史系统里用过，出来的数字永远比实际多或少几天，最后还得人工兜底。能建日历表就建，别跟算法较劲。
5. 性能：函数写到列上，索引就废了
5.1 谓词可索引性的基本盘
这点很多人写报表时不注意，量大了直接卡死。原则一句话：函数包裹的列，索引大概率用不上。
-- 反例：索引列被函数包裹，走全表扫描 SELECT * FROM 模拟账期表 WHERE DAYS(DATE(开始时间)) = 739000; -- 正例：让函数待常量那边，列保持原样 SELECT * FROM 模拟账期表 WHERE 开始时间 >= TIMESTAMP('2024-03-01-00.00.00') AND 开始时间 < TIMESTAMP('2024-03-02-00.00.00');第二段之所以能走索引，是因为开始时间这个列裸着出现在谓词左侧，可以直接拿索引树定位。第一段因为给列套了DAYS()，优化器没法用索引，只能逐行算。
SELECT 列表里用DAYS()是完全没问题的，那只是个输出计算，不做过滤。问题只出现在 WHERE 和 JOIN 条件里。这个区分很关键，很多人一听“别用函数”就矫枉过正，连查询结果列都不敢用。
5.2 预计算和生成列：把开销前置
如果某个天数在报表里被反复查、数据量又大，我一般会把它落到表里。DB2 支持生成列：
ALTER TABLE 模拟账期表 ADD COLUMN 账期天数 INT GENERATED ALWAYS AS ( DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) );这样写入时自动算好，查询时直接读列，还能建索引。代价是结束时间更新时这个列会跟着重算，写多读少的表要谨慎评估。
如果不方便改表结构，退一步可以建个汇总表，用定时任务夜间刷一遍：
INSERT INTO 账期汇总表 SELECT 单据号, DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) AS 账期天数, CURRENT TIMESTAMP AS 刷新时间 FROM 模拟账期表 WHERE 状态 = '结清';日终跑批的思路虽然土，但胜在稳，出问题也好回溯。
5.3 大表刷数时的一个小技巧
批量更新历史数据时，全表一条语句跑很容易长时间持锁。我一般按批次切：
UPDATE 模拟账期表 SET 账期天数 = DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) WHERE 账期天数为空 FETCH FIRST 5000 ROWS ONLY;DB2 的UPDATE ... FETCH FIRST需要较新版本支持，老版本上得用游标或者WHERE 主键 IN (SELECT ... FETCH FIRST N ROWS ONLY)绕一下。分批跑加上短暂间隔，对线上影响能压到很低。
提示：批处理前先
SELECT COUNT(*)估一下待处理量，再决定批次大小。我曾经按 5000 一批去刷 200 万行，跑了快一个小时，中间还因为锁等待超时中断了一次。后来改成 2 万一批，时间直接砍到十几分钟。
6. 常见问题与排查速查表
6.1 报错类问题
SQLCODE -181（日期时间值格式无效）：八成是日期格式不对或者字符串里有脏数据。先跑SELECT 列 FROM 表 WHERE 列 IS NOT NULL FETCH FIRST 10 ROWS ONLY肉眼看几条，往往能立刻发现2024-02-30或者2024/3/1这种鬼东西。
SQLCODE -4200（函数参数类型不匹配）：常见于把VARCHAR直接塞进DAYS()。加一层DATE()或者TIMESTAMP()显式转换，问题基本能解决。
SQLCODE -122（未提供数值数据）：DAYS()的参数是空字符串''，不是NULL，但转换失败。这种数据在清洗阶段就要处理掉。
6.2 结果不对类问题
这类更麻烦，因为不报错。我总结了一张对照表，碰到数字对不上先按这个顺序查：
| 现象 | 最可能的原因 | 排查手法 |
|---|---|---|
| 跨月后结果小了很多 | 用了DATE - DATE直接相减 | 检查是否有列相减，改成DAYS |
| 结果总是比预期少 1 | 口径是含头含尾，漏了+1 | 找业务确认，补+1 |
| 结果总是比预期多 1 | 首尾都带时间，截断后仍多算 | 用MIDNIGHT_SECONDS校验精度 |
部分行结果为NULL | 起止有一列为空 | WHERE 结束时间 IS NULL查一下 |
| 出现负数 | 结束早于开始，数据异常 | 加WHERE 结束时间 >= 开始时间过滤 |
| 小数天全是整数 | 整数除法把小数吃掉了 | 分母写86400.0或套DOUBLE() |
| 同一张表两次查询结果不同 | 用了CURRENT DATE之类动态值 | 检查是否有跨零点执行的情况 |
最后一行值得多说一句。报表 SQL 里如果用CURRENT TIMESTAMP参与天数计算，凌晨跑批的时候，“今天”和“昨天”的边界会让结果跳变。我遇到过一次，同一个报表晚上十点跑和凌晨一点跑，差了一整天的数，查了大半天才发现是这个原因。跑批任务尽量传入固定基准时间作为参数，别让它自己取当前时间。
6.3 一个容易被忽略的细节：带时区的列
如果表里的列定义成TIMESTAMP WITH TIME ZONE，那它和普通时间戳的玩法不一样。两个带时区的时间做减法，DB2 会先折算到统一基准再算，这时候你得到的“天数”跟按本地日期截断算出来的“天数”可能对不上，尤其跨夏令时切换的那几天。
我的处理办法很简单粗暴：这类场景一律先显式转成本地时间戳再算，把时区因素消化在转换这一步，别让它悄悄混进天数计算里。
SELECT DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) AS 相隔天数 FROM 某业务表;如果DATE()对带时区类型的转换行为在你们版本上不理想，那就先CAST(... AS TIMESTAMP)再DATE()，多写一层总比算错强。
7. 几个我踩过的坑和手上常用的小技巧
写到这里，前面讲的都是能落在纸面上的规范。但真正让人头大的，往往是那些看起来不起眼的细节。说几个印象深的。
第一个是别拿DAYS()的返回值做业务判断。有同事写了个WHERE DAYS(create_time) > 730000，本意是“2024 年以后的数据”，结果硬编码的魔法数字随着时间推移逐渐说不清含义，后来没人敢动这段 SQL。要按日期范围筛选，直接用日期字面量比较，可读性和可维护性都是碾压级的。
第二个是打印调试用的中间结果。天数算不对的时候，我会先跑这么一段，把每一步拆开看：
SELECT 开始时间, 结束时间, DATE(开始时间) AS 开始日, DATE(结束时间) AS 结束日, DAYS(DATE(开始时间)) AS 开始天数轴, DAYS(DATE(结束时间)) AS 结束天数轴, MIDNIGHT_SECONDS(开始时间) AS 开始秒, MIDNIGHT_SECONDS(结束时间) AS 结束秒 FROM 模拟账期表 WHERE 单据号 = 'A002';一眼就能看出是哪一步跟预期对不上，比盯着一个最终数字猜要快得多。这个方法我教给过好几个新人，反馈都是“早知道能这么查就不用耗一下午了”。
第三个是统一封装。同一个系统里算天数的地方可能有十几处，如果每处都自己写一遍，迟早出现两种口径并存。我的做法是在数据库里建个视图或者定义一个标准表达式，全项目引用同一份：
CREATE VIEW 账期明细视图 AS SELECT 单据号, 开始时间, 结束时间, 状态, DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) AS 自然日天数, DAYS(DATE(结束时间)) - DAYS(DATE(开始时间)) + 1 AS 含头含尾天数 FROM 模拟账期表;以后谁要用天数，从视图里取列就行，口径天然一致。加字段的时候也只改一处，不用担心漏改。
最后分享一个个人习惯：任何涉及天数的 SQL，我都会在注释里写一行手算校验值。比如-- A001: 2/1 到 3/1，2024闰年，应为29天。这条注释看起来幼稚，但它让我在无数次重构和迁移中，第一次跑测试就能确认结果对不对。数据库版本升级、参数调整、SQL 重写，只要这行注释还在，验证成本几乎为零。
