日期加减计算
从一个起算日期往前或往后推算几天、几周、几个月、几年,并正确处理月底的情况。
在你的浏览器中运行
这一页回答什么
选一个起算日期、一个数字和一个单位,它会告诉你是哪一天。今天起算 90 天后、期限前六个月、 合约开始两年后。
结果会一并显示星期几——那通常是你第二个想知道、却总是忘记确认的事。
加一个月不等于加 30 天
有趣的情况就在这里,也是各家日期库互相不一致的原因:
1 月 31 日的一个月后是哪一天?
| 答案 | 理由 |
|---|---|
| 2 月 28 日 | 夹到目标月份的最后一天 |
| 3 月 3 日 | 月份加一,日期溢位让它自己滚过去 |
| 3 月 2 日 | 加 30 天 |
本页给的是 2 月 28 日——夹到月底——这也是几乎所有行事历软件、以及多数法律文书所说的「一个 月后」。闰年则是 2 月 29 日。
由此产生的结果是:月的运算不可逆。1 月 31 日的一个月后是 2 月 28 日,而 2 月 28 日的一个月 前是 1 月 28 日,不会回到你出发的 31 日。这不是计算器的缺陷,而是历法本身的性质;也正是为什么 重要的契约会写「当月最后一日」,而不是依赖这个运算。
| 起算 | 加一个月 |
|---|---|
| 1 月 31 日 | 2 月 28 日(闰年 29 日) |
| 3 月 31 日 | 4 月 30 日 |
| 1 月 30 日 | 2 月 28 日 |
| 2024 年 2 月 29 日 | 2024 年 3 月 29 日 |
2 月 29 日加一年
同样夹住。2024 年 2 月 29 日的一年后是 2025 年 2 月 28 日,四年后是 2028 年 2 月 29 日。
该用哪一个单位
它们不能互换,而选错是这里最常见的错误:
| 条文写的是 | 该用 | 因为 |
|---|---|---|
| 「90 天」 | 天 | 固定天数,不受月份长度影响 |
| 「3 个月」 | 月 | 落在相同的日号,实际是 89–92 天之后 |
| 「6 周」 | 周 | 落在相同的星期几 |
| 「1 年」 | 年 | 明年的同一天 |
90 天和 3 个月不是同一段期间。 从 1 月 1 日起算,90 天是 4 月 1 日,三个月也是 4 月 1 日 ——那是巧合。从 3 月 1 日起算,90 天是 5 月 30 日,三个月是 6 月 1 日。适用哪一个,完全取决于 条文怎么写。
周是唯一保证落在相同星期几的单位,这就是排班与周期性行程都以周指定的原因。
这里不提供「加几个工作日」
这是刻意的。要加「10 个工作天」就需要一份假日行事历,而假日因地而异、每年都在动——农历春节、 复活节,以及假日碰到周末后补上的每一个平日。一个宣称做得到的通用计算器,对大多数使用者来说 都会默默地算错。
日期相差计算确实会计算两个已知日期之间的工作日,但附带同样的但书: 只扣周末,不扣假日。
常见期间
| 期间 | 从 2026 年 1 月 1 日起算 |
|---|---|
| 30 天 | 2026 年 1 月 31 日 |
| 90 天 | 2026 年 4 月 1 日 |
| 6 个月 | 2026 年 7 月 1 日 |
| 1 年 | 2027 年 1 月 1 日 |
| 18 个月 | 2027 年 7 月 1 日 |