日期、时间与计划
月末加一个月和加 30 天一样吗？
使用工具
有效一个月与有效三十天听起来相同，从一月三十一日开始却不同。难点不在加法，而在单位含义。区分月、历日、经过时间，就能发现规范遗漏的约定。
用日期加减和日期差查看结果，工具不判断合同条款。先明确规则是下月同日、下月末还是固定时长。未决定时应把差异用于讨论，而不是选方便的答案。
一月三十一日加一个月与三十天
2024-01-31T12:00:00Z月设 1，其余 0、UTC、月末限制为有效日期，得到 2024 年二月二十九日中午；二月三十一日不存在，故限制到月末。同一来源改月 0、日 30，得到三月一日中午，替换单位就差一天。
只改成 2023 年，一个月后为二月二十八日，三十天后为三月二日，差距也随年份变化。平均月长不能复现实际更新日，比较记录应保留完整年月日。
修正日期还是拒绝操作
改为拒绝时，一月三十一日加一个月会报错，这是禁止擅自替代不存在日期的政策，并非故障。允许限制也应理解日期变为月末。下月没有三十一日就不可用，与改用月末是不同规则。
2024 年二月二十九日加一年同样需要决定，因为 2025 年二月无二十九日。生日、续期、结算可有不同规则；工具仅按选择处理，不从用途推测。
两次加一个月可能不同于一次加两个月
Jan 31 + 1 month = Feb 29
Feb 29 + 1 month = Mar 29
Jan 31 + 2 months = Mar 31首次调整已变二十九日，再以结果为来源就到三月二十九日，不会记住原本偏好三十一日。每月末计划不能仅重复加月，应明确每次从原锚点计算还是重新选月末。
反向也未必恢复：一月三十一日加月到二月二十九日，再减月到一月二十九日。调整丢失信息，不能假定可逆，应保留原日期核对。
一天后未必二十四小时后
2024-03-09T12:00:00-05:00在 America/New_York 加一天得到三月十日十二点 -04:00，只经过二十三小时；加二十四小时则为十三点。两者都正确但保留不同量：午餐固定当地中午，设备运行固定经过时长。
实验需同时确定日期、地区和源偏移。UTC 十二点与纽约十二点不是同一瞬间。月末处理也不是夏令时歧义选择；预约切换附近时刻应另用时区工具的当地模式检查缺失与重复。
历日差与经过时间分开读
历日模式比较 2024-03-09 与 2024-03-10 为一天；经过模式比较对应十二点 -05:00 与 -04:00 为二十三小时、82,800 秒。分模式是为了不替纯日期擅加时刻时区后称二十四小时。
若九日十日两端都计入，就是两个日期，与日期差一天不矛盾。营业日数应使用端点选项，不要把经过或历日差直接当包含日期数量。
截止日期先需要规则再需要数字
记录起点、时区、加算单位、月末规则和重复锚点。只有一个月后不足以复现。分别试月末、闰年和偏移切换日，能发现平常日期隐藏的差异。
工具不注册计划或读取服务续期日。与服务结果不同时先比较规则，起点相同不证明服务错误。解释规则比只得到日期更重要。
每月基准日未必从上次结果推算
从一月三十一日起，将补正后的二月底再加一月，可能把该日带到三月；从原始日期直接加两月则到三月三十一日。必须区分每月末、保留原日仅无该日时补正、前次结果后一月。开启月末补正并不等于定义了重复规则。
有效期还需定义结束时点：到三月三十一日为止与到该日零点不是同一区间。给纯日期擅自加一天开始或结束会改变可用时间。时区、端点包含和秒以下处理应由服务规格明确，日期计算只是执行规则，不自动消除措辞歧义。
普通日期之外还测月底、闰年二月、夏令时边界，记录原日、单位、补正规则与期望。往返有帮助，但补正可能丢失原日信息，加月再减月未必返回原值；应区分缺陷与既定规则的结果。