日期、時間與排程
月底加一個月和加 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 秒。分模式是為了不替純日期擅加時刻時區後稱二十四小時。
若九日十日兩端都計入，就是兩個日期，與日期差一天不矛盾。營業日數應使用端點選項，不要把經過或曆日差直接當包含日期數量。
截止日期先需要規則再需要數字
記錄起點、時區、加算單位、月底規則和重複錨點。只有一個月後不足以重現。分別試月底、閏年和位移切換日，能發現平常日期隱藏的差異。
工具不登錄計畫或讀取服務續期日。與服務結果不同時先比較規則，起點相同不證明服務錯誤。解釋規則比只得到日期更重要。
每月基準日未必從上次結果推算
從一月三十一日起，將補正後的二月底再加一月，可能把該日帶到三月；從原始日期直接加兩月則到三月三十一日。必須區分每月底、保留原日僅無該日時補正、前次結果後一月。開啟月底補正並不等於定義了重複規則。
有效期還需定義結束時點：到三月三十一日為止與到該日零點不是同一區間。給純日期擅自加一天開始或結束會改變可用時間。時區、端點包含和秒以下處理應由服務規格明確，日期計算只是執行規則，不自動消除措辭歧義。
一般日期之外還測月底、閏年二月、日光節約時間邊界，記錄原日、單位、補正規則與預期。往返有幫助，但補正可能丟失原日資訊，加月再減月未必返回原值；應區分缺陷與既定規則的結果。