天数加减计算器

天与周的平移是精确的；月与年的平移保持同一个日期号，只有当目标月不够长时才夹到那个月的最后一天

date

起始日期，它本身永远不被调整

amount

整数的天、周、月或年；填负数就是把日期往回推

unit

天与周是定长单位，月与年不是

shiftDays

真实移动的天数；只要涉及月或年，它就不等于上面那个数量

用它推算到期日、回访窗口或者订阅期的结束。天与周是定长单位，所以往后 14 天永远落在同一个星期几，实际移动天数也永远等于填进去的数量。月与年不是定长单位，所以加一个月可能移动 28、29、30 或 31 天，取决于从哪里开始——实际移动天数这个输出会告诉你究竟是哪一种。它做不到的是遵循合同自己关于期末的约定：如果协议写的是「期间在最后一个工作日结束」，那是另一套算法。

1. 2026 年 1 月 31 日过一个月

   1. 目标月份是 2026 年 2 月，它只有 28 天，没有 31 日可落
   2. 于是日期夹到那个月的最后一天，结果是 2026 年 2 月 28 日
   3. 实际移动天数：1 月 31 日到 2 月 28 日是 28 天，不是 31 天
   4. 星期几跟着结果走：2026 年 2 月 28 日是星期六

   夹取是这一页最容易被实现错的地方。把「过一个月」写成「加三十天」的工具，在这里会给 3 月 2 日。

2. 2024 年 1 月 31 日过一个月

   1. 2024 能被 4 整除且不能被 100 整除，是闰年，2 月有 29 天
   2. 同样没有 31 日可落，所以仍然夹到月末，只是这次的月末是 29 日
   3. 实际移动天数因此是 29 天，比平年同样的操作多一天
   4. 两条合起来说明：夹取的目标是「那个月的最后一天」，不是一个固定的天数

   同一个起始日、同一句指令，只因为年份不同就差一天。这个差异之所以看得见，是因为实际移动天数和日期一起被报了出来。

3. 2026 年 1 月 1 日往后 90 天

   1. 按天平移完全不做夹取：1 月 1 日往后 90 天就是 90 天之后的那个日期
   2. 2026 年 1 月有 31 天、2 月 28 天、3 月 31 天，31 + 28 + 31 = 90，正好走完三个月
   3. 所以落在 4 月 1 日，实际移动天数就是填进去的 90
   4. 2026 年 4 月 1 日是星期三，而 1 月 1 日是星期四——90 不是 7 的整数倍

   天与周是定长单位，这一条不会有任何意外。上面两条按月的才是意外所在。

月与年都不是定长单位，所以「加一个月」唯一说得通的定义是：落在同一个日期号上，或者当那个月不够长时落在它的最后一天上。这条夹取规则与电子表格一致，而改成「溢出到下个月」的工具会给出晚一到三天的答案。这里也不跳过周末与法定节假日——那要用工作日计算器。所有日期一律按推算格里高利历处理，不做任何历法改革。

日期加一个月怎么算？

先找到下个月的同一个日期号。那个月里有这一天就直接用它，没有就夹到那个月的最后一天。所以 3 月 15 日加一个月是 4 月 15 日，而 1 月 31 日加一个月是 2 月 28 日，闰年的 2024 年则是 2 月 29 日。

1 月 31 日过一个月是几号？

平年是 2 月 28 日，闰年是 2 月 29 日。日历上没有 31 日的 2 月，所以结果夹到目标月的最后一天，而不是溢到 3 月。电子表格用的就是这条规则，它也是「加一个月」可能只移动 28 天的原因。

日期减天数怎么写？

数量填负数就行，不需要另一个入口。从 2026 年 9 月 19 日减 10 天得到 9 月 9 日，实际移动天数显示为负十，方向在结果里看得见，而不只是藏在输入里。减一个月同样会夹取。

加一个月会保持同一个日期号吗？

只要目标月够长就会保持——3 月 15 日加一个月是 4 月 15 日。目标月较短时，日期号夹到那个月的最后一天：1 月 31 日加一个月是 2 月 28 日，3 月 31 日加一个月是 4 月 30 日。涉及 29、30、31 日的月份时，两套规则才会分道扬镳。

实际移动天数有什么用？

它把「过一个月」翻译成确切的数字。这个数字随起始日变化：从 1 月 31 日加一个月，2026 年是 28 天，2024 年是 29 天。凡是天数要紧的场合——利息、通知期、保修期——都应该看这个数，而不是看「一个月」这个词。

• relativedelta — the dateutil module — dateutil 项目文档
• 《中华人民共和国民法典》总则编 第十章 期间计算（第二百零二条） — 旬邑县人民政府门户网站（《民法典》条文）