日付計算ツール

月の1日目から8日目まで数えると、2つの日付の間に正確に7つの完全な夜が生まれます — 排他的なカウントで、これはそれらを隔てる完全な24時間期間の数です。しかし「7日以内」と言う契約、通知期間、賃貸契約は、非常にしばしば包括的に数えます。開始日と終了日の両方を、その間に何もない境界マーカーとしてではなく、数えられる日として扱うのです — その読み方の下では、1日目から8日目までの同じ範囲は8日と解釈されるかもしれません。どちらの慣習も普遍的に「正しい」わけではありません — それらは本当に異なる質問に答えており、これがこのツールが両方の数字を表示する理由です。特定の文言が重要になるたびに一方を選んで他方を別に計算させるのではなくです。

土曜日と日曜日を日数のカウントから除外することは、契約、法的な締め切り、配送見積もりにおいてほぼ普遍的な慣習に近いです。5日制の労働週がほぼ世界標準に近いためです。祝日はまったく別の問題です — 国ごとだけでなく、しばしば州、地域、あるいは国内の都市によっても異なり、このツールが各ユーザーに対して正しく適用できる単一の権威あるカレンダーはありません。祝日の処理をユーザーに任せながら週末を除外することが正直なアプローチです: 特定の祝日が本当に重要な締め切りについては、関連する管轄区域の公式祝日カレンダーを別途確認することが、この計算ツールが代替できない必要な追加ステップです。

1月31日にカレンダー月を加算しても文字通り「2月31日」を生み出すことはできません。2月に31日があることは決してないためです — ほぼ普遍的な慣習であり、このツールが従うものでもありますが、代わりに対象月の最後の有効な日に落ちることです。通常の年では2月28日、閏年では29日になります。これには知っておく価値のある本当に驚くべき結果があります: 1月31日に1か月を加算し、その結果から1か月を引いても、必ずしも1月31日には戻りません。中間の日付はすでに1月が持っていて2月が持っていない余分な日数を失っているためです。これはこのツール特有のバグではありません — 月の長さが異なることの避けられない帰結であり、月の算術を扱うどんな日付ライブラリも、まったく同じ曖昧さに直面します。

日付ツールにおけるよくある微妙なバグは、「2026年3月15日」のような平坦なカレンダー日付を、UTC時間の特定の瞬間として扱い、それから表示のためにその瞬間を閲覧者のローカルタイムゾーンに変換することから来ます — これは、ローカルタイムゾーンがUTCからどれだけ離れているかによって、表示される日付を1日前後にずらすことがあり、タイムゾーンの境界近くで黙って間違った日を出す日付計算ツールを生み出します。このツールは日付を、時刻やタイムゾーンの要素をまったく持たない平坦なカレンダー日付として扱います。まさに紙のカレンダーが機能する方法どおりです。これは、それを避けるために慎重にタイムゾーンを管理する必要があるのではなく、この種のバグ全体を完全に回避します。