日期加天数计算器

基准日加增量的天级推算,附星期、年内序数、周天分解与途经闰日计数。

默认示例:2026-01-15 + 47 天 = 2026-03-03(星期二),47 天 = 6 周 5 天

使用方法

  1. 在「基准日期」选起始日,示例用 2026-01-15;年份限 1900~2999,原因见「边界与精度」。
  2. 在「天数增量」填 -36500 ~ 36500 的整数,负数即往前推(示例填 47)。
  3. 点「计算目标日」,或在任一输入框按回车,结果区给出目标日、星期、年内第几天、周天分解、跨月跨年标记与途经闰日数。
  4. 点「载入示例」回到 2026-01-15 + 47 的默认组合;点「复制结果」带走当前一行结论。
  5. 下方对照表预置十二组典型用例,点「加载更多」续看十二组,「导出 CSV」下载带 BOM 文件。

这个日期加天数计算器能解决什么问题

第一,交付与合同场景的「N 个工作日之后的自然日落点」。先得到目标日,再用工作日计算器剔除休息日,两步各司其职。

第二,验证闰年口径。2024-02-28 加 1 天是 2024-02-29,而 2026-02-28 加 1 天是 2026-03-01——同样「+1 天」在闰年与平年落点不同,手工排期最容易在这里错一天。

第三,把「N 天」翻译成人能读的单位。47 天是 6 周零 5 天、落在第 62 天,跨了 1 个月、途经 0 个闰日;这是月日期计算器或年龄计算器不提供的视角——它们算两点的间隔,本页算增量的落点。

本页不做的事:不算两个日期之间的间隔天数(那是日期间隔天数计算器与日期差值计算器的职责)、不剔除节假日、不支持「加 N 个月」——月与年不可用固定天数换算,2026-01-15 到 2027-01-15 是 365 天,2024-01-15 到 2025-01-15 却是 366 天,差的那天就是 2 月 29 日。

原理和变量

日期加天数计算器的核心算法是时间戳平移:一天恒等于 24 × 60 × 60 × 1000 = 86400000 毫秒,目标时间戳 = Date.UTC(年, 月-1, 日) + 增量 × 86400000。关键在于必须走 Date.UTC 而不是本地时区构造——东八区的 new Date(2026, 0, 15) 比 UTC 表示早 8 小时,两种口径相减会出现半整数天;用 Date.UTC 把基准与目标都钉在 UTC 零点上,差值除以 86400000 恒为整数,时区与夏令时误差被整体消掉。

闰年判定遵循公历(格里高利历)三条规则:能被 4 整除且不被 100 整除,或能被 400 整除。三条例子都已实测:1900 能被 100 整除,非闰;2000 能被 400 整除,闰;2100 两者都不满足,非闰。按此规则 2000~2099 这 100 年里恰好 25 个闰年,平年 365 天、闰年 366 天,差的一天就是 2 月 29 日。

「途经闰日」的计数口径:正向增量统计开区间 (基准, 目标] 内的 2 月 29 日时间戳,负向统计 (目标, 基准]。实现按年循环逐个闰年取 Date.UTC(年, 1, 29) 判落,增量上限 36500 天约 100 年,循环最多百次量级,开销可忽略。

年内序数(day of year)= 目标时间戳与当年 1 月 1 日时间戳之差除以 86400000 再加 1。2026-03-03 是第 62 天;平年 12 月 31 日是第 365 天,闰年(如 2024)是第 366 天,差的 1 就是当年闰日。

完整示例(数值仅作演示)

按日期加天数计算器的默认组合:基准 2026-01-15、增量 47,目标时间戳相加后落在 2026-03-03,星期二,年内第 62 天(全年 365 天)。分解:47 = 6 × 7 + 5,即 6 周 5 天。手工核对口径:1 月剩 16 天(1/16 至 1/31),2 月平年 28 天,16 + 28 = 44,47 − 44 = 3,落进 3 月 3 日,与时间戳算法一致。途经闰日 0 个(2026 非闰年)。换基准 2024-02-28、增量 1,结果直接给出 2024-02-29 而不是 03-01,途经闰日计 1。

输入范围与对照表

基准年合法区间 1900~2999,增量合法区间 -36500 ~ 36500(约正负一百年)。下表十二组用例覆盖零增量、整周、跨月、跨年与闰日边界,全部经脚本按同一算法复算:

#基准日增量目标日星期落点
12026-01-1502026-01-15四同月
22026-01-15+72026-01-22四同月
32026-01-15+302026-02-14六跨月 → 2 月
42026-01-15+472026-03-03二跨月 → 3 月
52026-01-15+3652027-01-15五跨年 → 2027
62026-02-28+12026-03-01日跨月 → 3 月
72024-02-28+12024-02-29四同月(闰日)
82024-02-28+22024-03-01五跨月 → 3 月
92026-12-31+12027-01-01五跨年 → 2027
102026-03-01-12026-02-28六跨月 → 2 月
112026-01-01-12025-12-31三跨年 → 2025
122026-06-15+2002027-01-01五跨年 → 2027

第 6 与第 7 行并排看最直观:同样是 2 月 28 日加 1 天,2026 落到 3 月 1 日、2024 落到 2 月 29 日,两天之差全在闰日规则里。第 5 行的 +365 天并没有「加一年」——2026 全年 365 天,目标日星期从四变五,因为 2026-01-15 是星期四,365 = 52 周 + 1 天。

边界与精度

年份下限定在 1900 有个具体原因:Date 构造对 0~99 的两位年份有映射陷阱,Date.UTC(99, 0, 1) 的结果不是 2099 年而是 1999 年(规范规定 0~99 映射为 1900 + 年)。本页不接受两位年份输入,date 输入框的 min 属性加上解析层的四位数校验双保险,避免静默落到一百多年前。

增量两端各测过一次:2026-01-15 + 36500 = 2125-12-22,2026-01-15 − 36500 = 1926-02-09,落点都远在四位年份区间内。JavaScript 的 Date 可表示范围约正负 2.7 亿年,本页 ±100 年的窗口远未触界;toISOString 只能安全输出 0000~9999 年,年份过万会抛 RangeError,本页上限保证到不了那里。

天级平移不需要月末夹取—— setDate 溢出问题只出现在「加月份」场景(1 月 31 日加 1 个月在 2 月只有 28 天),按天数走整数毫秒加法天然无此歧义。这也是本页只做天、不做月的原因之一:口径混在一起反而容易把 2026-01-31 加 1 个月算成 3 月 3 日(2 月 31 日溢出的真实行为)。

非法输入四条路径各有文案:未选基准日、增量留空、增量非整数(如 1.5 天在日历上无意义)、增量超出 ±36500,均会指出字段与允许范围,绝不静默按 0 处理——按 0 会得到「目标日就是今天」的假结果。

常见问题

为什么结果按 UTC 算不会差一天?

基准与目标都用 Date.UTC 钉在零点,两者之差是 86400000 的整数倍,与浏览器时区无关。如果用本地时间构造再相减,东八区会带 8 小时偏移,除以一天的毫秒数就不再是干净整数。

2100 年是闰年吗?

不是。2100 能被 4 整除也能被 100 整除,但不满足「能被 400 整除」这条,所以 2100 年 2 月只有 28 天。同理 1900 年也不是闰年,2000 年和 2400 年是。跨 2100 年的推算本页按此口径处理。

加 365 天等于加一年吗?

不等于。2026-01-15 加 365 天得 2027-01-15,是因为 2026 全年 365 天;但 2024-01-15 加 365 天只得 2025-01-14,因为 2024 有 366 天。真正的「加一年」要按日历月推进,那是月日期计算器的口径。

途经闰日为什么要定成开区间?

基准日本身不算「途经」:从 2024-02-29 出发加 1 天,结果 3 月 1 日,途经闰日应为 0,因为 2 月 29 日是起点不是途中经过的日子。目标日恰是闰日时计入,这样「+1 天跨闰日」才会报 1。

填小数天可以吗?

不接受。1.5 天在日历上没有落点,本页按整数拒绝并提示;需要按小时推算请用时间戳类工具,两条口径混在一个输入框里只会制造歧义。

为什么年份不让填两位?

Date.UTC(99, 0, 1) 会被规范映射成 1999 年而不是 2099 年,这种静默改写在日期计算里是灾难性的。本页在输入层就只接受 1900~2999 的四位年份,让陷阱根本没机会触发。

和日期间隔天数计算器是什么关系?

方向相反:那页给两个日期算差值,本页给基准加增量算落点。本页额外报告落点的星期、年内序数与途经闰日,这些是「差值口径」不输出的量。两页各配一组对照表,不重复。

计算和表格会上传吗?

不会。日期加天数计算器只调用 Date.UTC 与整数乘加,CSV 是浏览器本地拼字节流下载,全程无网络请求,刷新后输入即清空。

相关工具

更多时间类目见日期时间分类页。