日期计算器

从某月 1 号数到 8 号,两个日期之间恰好经过 7 个完整的夜晚——这是不包含端点的计数方式,即两者之间完整的 24 小时周期数。但一份合同、通知期限或租约上说的"7 天以内",很多时候是按包含端点的方式计数的,把起始日和结束日都当作被计数的天数,而不是两端之间什么都没有的边界标记——按这种理解,同样从 1 号到 8 号的这段时间,可以被解读为 8 天。这两种惯例都不是普遍意义上"正确"的;它们回答的是真正不同的问题,这正是为什么这个工具会同时显示这两个数字,而不是选定一个、把另一个留给用户在具体措辞真正要紧时自己去算清楚。

在统计天数时排除周六和周日,在合同、法律截止日期和物流估算里几乎是一条普遍适用的惯例,因为五天工作制在全球范围内已经接近标准。公共假期则完全是另一回事——它们不仅因国家而异,往往还因一个国家内部的州、地区甚至城市而异,没有任何单一的权威日历能让这个工具对每一个用户都正确应用。排除周末、把假期处理留给用户,是诚实的做法:对于一个具体公共假期真正重要的截止日期,单独核对相关司法辖区的官方假期日历,是这个计算器无法替代的一个必要额外步骤。

给 1 月 31 日加一个日历月,不可能真正得到"2 月 31 日",因为 2 月从来没有 31 天——这个工具遵循的、也是近乎普遍的惯例,是落在目标月份最后一个有效日期,普通年份是 2 月 28 日,闰年是 29 日。这会带来一个确实令人意外、值得了解的后果:给 1 月 31 日加一个月、再从结果减一个月,不一定能回到 1 月 31 日,因为中间那个日期已经丢失了 1 月比 2 月多出的那几天。这不是这个工具特有的 bug——它是月份长度各不相同带来的不可避免的后果,任何处理月份运算的日期库都会面临同样的歧义。

日期工具里一个常见又隐蔽的 bug,来自把一个普通的日历日期,比如"2026 年 3 月 15 日",当作 UTC 时间里的一个具体时刻,再把这个时刻转换成查看者的本地时区来显示——这可能会根据本地时区距 UTC 有多远,把显示出来的日期往前或往后偏移一天,产出一个在时区边界附近悄悄算错日子的日期计算器。这个工具把日期当作完全不带时间或时区成分的纯日历日期来处理,就像一本纸质日历那样,这从根本上绕开了这一整类 bug,而不需要为了避免它而小心翼翼地管理时区。