📅 日付計算ツール
2 つの日付の差・日付の加減算・営業日 (土日祝除外)・年齢を一発計算。YYYY-MM-DD / YYYY/MM/DD / YYYY年MM月DD日 を自動判定、タイムゾーン対応。
🔒 プライバシーについて
- ・すべての計算はブラウザ内で完結します
- ・入力した日付や祝日リストは一切サーバーに送信されません
- ・登録・ログイン・課金は一切不要です
💡 入力フォーマットは YYYY-MM-DD / YYYY/MM/DD / YYYY年MM月DD日 を自動判定
📖 つまずきやすいポイント
2 つの日付の差、日付の加減算、営業日 (土日と任意の祝日を除外)、年齢を計算します。YYYY-MM-DD / YYYY/MM/DD / YYYY年MM月DD日 を自動判定し、タイムゾーンも指定できます。処理はブラウザ内で完結します。日付の計算には「唯一の正解」がありません — 期間を何日と数えるか、月をまたぐ加算をどう扱うかは規約で決まるもので、実装がどう振る舞うかとは別の話です。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 日数の差が 1 日ずれる | 「4 月 1 日から 4 月 3 日まで」は2 日でしょうか、3 日でしょうか。引き算をすれば 2 ですが、日常語の「3 日間」は 1 日・2 日・3 日を数えた結果です。この違いは「初日を算入するかどうか」で、業界と文脈によって答えが変わります — 宿泊日数は引き算 (2 泊)、勤務日数は両端を含む、契約期間は契約書の定義次第です。日本の民法は「初日不算入」を原則としています (翌日から数える) が、実務ではこの原則と違う数え方が契約で定められていることのほうが多いので、法律の原則を知っていても答えは出ません。 | 仕様書や契約書に「初日を算入するか」を明記してください — これは実装で決めることではなく、関係者の合意として先に決めておくべきことです。実装側では、変数名に意図を込めるのが最も効果的です — days ではなく nights や inclusive_days と書けば、読む人が取り違えません。テストには必ず「同じ日」のケースを入れてください — 4 月 1 日から 4 月 1 日までは 0 日か 1 日かで、この 1 件が仕様を明確にします。境界は 1 日ずれても動くので、テストが無いと本番まで気付きません。 |
| 月の加算が期待どおりでない | 1 月 31 日の 1 か月後は何日でしょうか。2 月 31 日は存在しないので、実装によって 2 月 28 日 (月末に丸める)、3 月 3 日 (31 日を足して繰り上げる)、3 月 1 日 のいずれかになります。どれも「間違い」ではなく、規約の違いです。さらに厄介なのは可換でないことで、「1 か月後の 1 か月前」が元の日付に戻らないことがあります — 1 月 31 日 → 2 月 28 日 → 1 月 28 日。サブスクリプションの課金日で毎月 31 日を選ぶと、この問題に毎月ぶつかります。 | 月単位の加算をする前に「月末をどう扱うか」を決めてください — 一般的なのは「存在しない日は月末に丸める」で、これが最も直感に近く、ほとんどのライブラリの既定でもあります。課金や契約更新のように「日付が意味を持つ」場面では、そもそも 29 日以降を選べないようにするのが最も安全です — 多くのサブスクリプションサービスがこの設計を採っているのは、この問題を避けるためです。月末締めが必要なら「毎月末日」という別の概念として実装してください — 「1 月 31 日 + 1 か月」ではなく「翌月の最終日」と定義すれば、曖昧さが消えます。 |
| 営業日の計算が国や年でずれる | 祝日は毎年変わります。日本の場合、成人の日・海洋の日・敬老の日・スポーツの日は「第 n 月曜日」なので日付が毎年動き、春分・秋分は天文計算で決まるため前年の官報で確定します。さらに日曜と重なると振替休日が発生し、祝日に挟まれた平日は休日になります。国をまたぐと状況はまったく変わり、同じ「営業日 5 日」でも、日本・米国・中国・イスラム圏では終わる日が違います — とくに中国の春節と中東の金曜休みは、日本の感覚から大きく外れます。 | このツールは祝日リストを自分で入力する方式なので、リストが古ければ結果も古くなります。日本の祝日は内閣府が CSV を公開しているので、そこから毎年更新してください — 「去年のリストを使い回す」のが、この種の計算でいちばん多い間違いです。複数国が絡む納期計算では、必ず国ごとに別々のリストで計算してください — 「営業日」という言葉が同じでも、意味する日が違います。そして、計算結果が納期や支払期日になる場面では、必ず先方と日付そのものを確認してください — 「5 営業日後」ではなく「◯月◯日まで」と合意すれば、数え方の違いは問題になりません。 |
日付だけを扱っているつもりでも、タイムゾーンは効いてきます。2024-01-01 を UTC で解釈するか日本時間で解釈するかで、同じ瞬間が 1 月 1 日にも 12 月 31 日にもなります — 日本時間の 1 月 1 日 8 時は、UTC ではまだ 12 月 31 日 23 時です。サーバーが UTC、利用者が日本という構成では、「今日の集計」が日本時間の 9 時に切り替わるという現象が起きます。データベースに「日付」を保存するときは、時刻を持たない DATE 型を使うか、必ず UTC に統一してください。もう 1 点、誕生日や記念日は「瞬間」ではなく「その地域の暦の上の日付」です — 1990 年 5 月 3 日生まれの人は、どこにいても 5 月 3 日が誕生日で、飛行機で日付変更線を越えても変わりません。こうした値にタイムゾーンを持たせると、海外からアクセスしたときに 1 日ずれます — 時刻を持たせないほうが正しい場面があると覚えておいてください。
📖 使い方
-
1
モードを選ぶ期間 / 加減算 / 営業日 / 年齢 のいずれかを上部タブから選択。
-
2
日付を入力YYYY-MM-DD / YYYY/MM/DD / YYYY年MM月DD日 のいずれかで入力。
-
3
計算する「計算する」をクリックすると結果が下に表示されます。
❓ よくある質問
入力した日付はサーバーに送信されますか？
うるう年や月末の扱いは？
祝日リストはどう書きますか？
🔗 関連ツール
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。