うるう秒と旧式のゾーン名

うるう秒を表す秒の 60 と、EST という旧式のゾーン名を含む 2 行の例です。うるう秒が次の分の 0 秒として繰り上がることと、旧式の名前の警告を確かめます。

入力

Date の値(1 行に 1 つ)

Thu, 31 Dec 2026 23:59:60 +0000
Wed, 28 Oct 2026 10:00:00 EST

換算先のゾーン

協定世界時 UTC(+0000)

結果

エラー 0 件・警告 1 件・情報 1 件

指摘(エラー・警告・情報)

  • 情報 1 行目 秒が 60(うるう秒)です。書式では許されますが、ここでは次の分の 0 秒として換算しました(RFC 5322 3.3)。
  • 警告 2 行目 ゾーン名「EST」は旧式の書き方です。送る側は +hhmm の形で書く決まりで、EST は -0500 として読む規則です(RFC 5322 4.3)。
換算した行2 / 2
換算先UTC(+0000)

変換した時刻

変換した時刻
入力の Date読み取ったゾーンUTC換算先の時刻時差
Thu, 31 Dec 2026 23:59:60 +0000+00002027-01-01 00:00:00(金) UTC2027-01-01 00:00:00(金) UTC(+0000)元の表記と同じ時差
Wed, 28 Oct 2026 10:00:00 ESTEST(旧式の名前。-0500 として換算)2026-10-28 15:00:00(水) UTC2026-10-28 15:00:00(水) UTC(+0000)元の表記より 5 時間 進む

検算(この結果になる理由)

2026 年 12 月 31 日 23:59:60 は次の分の 0 秒として扱うため、UTC では 2027 年 1 月 1 日 00:00:00 になります。EST は -0500 と読む規則なので 10:00 は UTC の 15:00 で、旧式の警告が出ます。

判定の根拠は仕様と根拠に、仕様の出典とともにまとめています。自分の入力で試すにはツールをお使いください。

このツールの制約

ご利用にあたって

  • 結果はヘッダーに書かれた値の換算で、メールが実際に送られた時刻を保証するものではありません。
  • 重要な時刻の確認には、受信側サーバーが付けた Received の日時も合わせて参照してください。

ほかの入力例