schedule Unixタイムスタンプ変換ツール star

仕組み

Unixタイムスタンプは、1970年1月1日 00:00:00 UTC(エポックと呼ばれる固定の基準点)からの経過秒数全体を数えます。1,784,000,000という数値は2026年7月に該当します。1970年以降のすべての秒には固有の整数が割り当てられており、タイムゾーン、暦月、夏時間といった概念は一切組み込まれていません。だからこそデータベース、API、ログファイルはこの方式で時刻を保存するのです。地球の反対側にある2台のサーバーが、同じ瞬間について同じタイムスタンプを計算し、タイムスタンプを数値として並べ替えることは、それらを時系列で並べ替えることと同じ結果になります — 日付を解析するロジックは一切不要です。

タイムスタンプを人間が読める日付に変換するとは、その整数を特定のタイムゾーンに照らして解釈することを意味します。基となる瞬間そのものは変わらず、表示のされ方だけが変わります。このツールは、食い違いをすぐに見つけられるよう、あなたのローカルタイムゾーンとUTCを並べて表示します — たとえばタイムスタンプ1784000000は2026-07-13 22:13:20 UTCと読み取れ、UTC+3では2026-07-14 01:13:20になります。逆方向 — 日付からタイムスタンプへの変換も同じロジックが逆に働きます。ツールは入力された日付の各項目を、選択したタイムゾーンに属するものとして扱い、対応するエポック整数を計算します。秒とミリ秒は桁数によって自動的に判別されるため、どちらの形式を貼り付けても設定なしで機能します。

知っておくべきこと

従来の32ビット符号付き整数は、エポックから最大2,147,483,647秒までしか数えられず、これは2038年1月19日03:14:07 UTCに到達します — いわゆる「2038年問題」です。タイムスタンプを32ビットで保存し続けているシステムは、その瞬間に負の数へと巻き戻ってしまい、精神的にはY2K問題によく似ています。現代の64ビットシステムでは同じ値をはるかに大きな整数で保存するため、およそ2920億年にわたって有効であり、現在のデータベース、OS、プログラミング言語は影響を受けません。負のタイムスタンプも有効です — 単に1970年1月1日より前の日付を、逆方向に数えて表しているだけです。もう一つ知っておくべき細かな点として、UTCは地球の自転との整合を保つために時折うるう秒が挿入されますが、Unixタイムスタンプの規格はうるう秒を完全に無視し、すべての1日をちょうど86,400秒として扱います — これによりタイムスタンプの計算はシンプルに保たれますが、その代償として天文学的な厳密さは失われます。

Unixタイムスタンプは日常の開発作業のあらゆる場面に登場します。JSON Web Tokenはその有効期限をexpクレームとしてエポック秒で符号化し、HTTPキャッシュヘッダーやクッキーも同様の方法で有効期限を設定することが多く、スケジューリングシステムは現在のエポック値と目標値を比較して発火のタイミングを決めます。この形式は単なる整数であるため、日付の演算は非常に単純です。タイムスタンプに86,400を加えることは、それがどの月やうるう年に該当するかに関わらず、UTCで常にちょうど1日後を意味します — これはカレンダー日付での演算をはるかに間違えやすくしているものです。ほぼすべてのプログラミング言語が「現在時刻」をタイムスタンプとして読み取るシンプルな関数を提供しているのもこのためです — PHPのtime()、JavaScriptのDate.now()、Pythonのtime.time() — そして2つのタイムスタンプを単純な数値として比較するだけで、それぞれの出来事が世界のどこで起きたかに関わらず、どちらが先に起きたかが分かります。