Unix タイムスタンプ ⇄ 日時

機能

• 現在のタイムスタンプをリアルタイム表示（秒とミリ秒を並記）。一時停止も、クリックして入力欄へ入れることも可能
• 方向ごとに1パネル：タイムスタンプ → 日時、日時 → タイムスタンプ
• 日時は標準のカレンダーで選ぶか、2026-09-18 15:30:45 のようなテキストを貼り付け
• 秒とミリ秒は自動判別。手動での指定も可能
• よく使うタイムゾーン 20 種。インド +05:30、オーストラリア +10:30 のような30分単位のオフセットも含みます
• オフセットは変換する瞬間の値で取るので、夏時間や過去のルール変更で1時間ずれることがありません
• 夏時間で飛ばされた時刻はエラーにし、二度来る時刻は両方を提示 —— 黙ってずらしません
• 結果は秒・ミリ秒・選択中のタイムゾーン・UTC・ISO 8601・RFC 2822 を行ごとに表示し、1行ずつコピー可能
• 一括変換：1行に1件、タイムスタンプと日時の混在も可。1行の失敗が他に影響しません
• 一括の結果は TSV としてコピー、または CSV としてダウンロード

使い方

1. 現在のタイムスタンプが欲しいときは、上部の数字をクリックすれば入力欄に入ります
2. タイムスタンプ → 日時：1つ目のパネルに貼り付け、単位とタイムゾーンを選びます
3. 日時 → タイムスタンプ：カレンダーで選ぶか、テキストを貼り付けます
4. 各行の右にある「コピー」で、その値だけを取り出せます
5. 一度にたくさん変換するときは「一括変換」に切り替え、1行に1件で貼り付けます

よくある質問

タイムゾーンの計算は正確ですか？

ブラウザ内蔵の IANA タイムゾーンデータベースに基づいて計算します。つまり夏時間の開始・終了日や、過去にルールが変わった国（モスクワが 2011 年に通年 UTC+4 へ、2014 年に UTC+3 へ戻した例など）も、計算するその瞬間のルールで解決されます。固定のオフセット表を引いているわけではありません。一覧は四百余りある全ゾーンではなく、よく使う二十数個に絞っています —— 長い尾を並べるほど、目的のものが見つけにくくなるだけだからです。

データがどのタイムゾーンのものか分からないときは？

UTC で計算してください。タイムゾーンを間違えると結果が丸ごと数時間ずれますが、そのずれは画面上では見えません —— 日時は正しい形式のまま表示されるからです。サーバーログがどのゾーンで書かれたか分からない場合は、「たぶんこれだろう」で選ぶより、UTC で変換して自分でオフセットを足し引きするほうが確実です。

夏時間の切り替わる日はどう計算しますか？

夏時間が始まる日には、そのゾーンに存在しない時刻があります（例：ニューヨークの 2026-03-08 02:30）。このツールはそれを明示的にエラーにし、飛ばされた区間を伝えます。01:30 や 03:30 に黙ってずらすことはしません —— ずらした結果は一見まともで、実際には1時間ずれているからです。夏時間が終わる日には同じ時刻が二度来ます（例：ニューヨークの 2026-11-01 01:30）。その場合は両方のタイムスタンプを並べ、既定では早いほうを採ります。

入力した日付形式が受け付けられないのはなぜですか？

受け付ける形式は決まった数種類だけです（2026-09-18、2026-09-18 15:30、2026-09-18T15:30:45）。JavaScript の new Date(文字列) はエンジンごとに解釈が違い、同じ入力が違う日付になり得るのにエラーも出ません。09/18/2026 のように米式とも欧式とも読める書き方は推測せず拒否します。2月30日のような存在しない日付も同様にエラーにし、黙って繰り上げたりはしません。

2038年問題とは何ですか？

秒を符号付き32ビット整数で持つシステムが 2038-01-19 03:14:07 UTC にオーバーフローする問題です。このツールは内部をミリ秒で計算し、およそ±27万年まで扱えるので、2038年より先の日時も問題なく変換できます。

19桁の数字が範囲外になるのはなぜですか？

19桁の数字は、タイムスタンプよりもスノーフレーク ID やデータベースの主キーである可能性のほうが高いです —— ミリ秒のタイムスタンプは現在13桁です。そうした値には基数変換ツールをお使いください。

データはサーバーへ送られますか？

いいえ。変換はすべてブラウザのメモリ内で完結し、ページはリクエストを一切送りません。オフラインでもそのまま使えます。