日本では公文書や新聞で「令和6年3月5日」のように元号が使われる一方、システムやAPIでは西暦の「2024-03-05」が使われる——同じ日付でも表記体系が二重に存在し、変換を誤ると日数計算そのものが狂ってしまう。
元号と西暦、どちらで数えているか
令和は2019年5月1日に始まった元号で、令和6年は西暦2024年にあたる。元号年をそのまま西暦の数値のように引き算してしまうと、当然まったく違う結果になる——「令和3年から令和6年」は3年間だが、数値だけを見て「2024-2019=5」のような誤変換をすれば答えが合わない。日付差分を扱うツールやコードは、必ず西暦（グレゴリオ暦）に統一してから計算する必要がある。
年月日の並び順という別の落とし穴
日本語の日付は「年月日」の順（例：2024年3月5日）だが、アメリカ式の03/05/2024は月が先に来るため3月5日を意味し、多くの国で標準の05/03/2024（日が先）とは異なる日付を指す。海外のAPIやスプレッドシートから来た日付をそのまま日本の感覚で読むと、月と日を取り違えたまま計算してしまうことがある。
タイムゾーンと日の境界
日付が時刻も含む場合、タイムゾーンの違いによって日数計算の結果が1つずれることがある：東京の23時30分とロンドンの15時30分は同じ瞬間でも、どちらのタイムゾーンで数えるかによって異なるカレンダー日に落ちることがある。
なぜこれが必要か
- 締め切りまでの正確な日数やプロジェクト開始日からの日数を計算する。
- 契約、サブスクリプション、保証期間がまだ有効かどうかを確認する。
- 海外システムから来た日付の年月日の並びを誤読していないか検証する。
「月の差」に唯一の正解がない理由
3月31日から1ヶ月を引くと結果は曖昧になる——2月31日は存在しないため、2月28日に丸めるシステムもあれば、超過分を3月3日に繰り越すシステムもある。どちらも理屈は通っているが答えが一致しないため、別のツールと結果が食い違ったときはまずこの境界条件を疑うとよい。