無料 Unix エポックタイムスタンプコンバーター

Unix時間(エポック)とは?

Unix時間(POSIXとも呼ばれる)は、コンピューティングで時間を表現する標準的な方法です。1970年1月1日午前0時0分0秒UTCから経過した秒数(またはミリ秒数)をカウントします。この単一の数値により、システムや時間帯間で時間の保存、比較、差の計算が容易になります。

1970年1月1日の選択、そしてその他のエポック

1970-01-01 のエポックは Bell Labs の Unix の起源にさかのぼります。Unix の time_t 型はもともと、選ばれた基準点からの秒数をカウントする符号付き32ビット整数でした。チームは開発開始直前の最も近い元日、つまり 1970年1月1日を選びました。決定は実用的なもので、哲学的なものではありませんでした。Unix は1969年から1971年にかけて開発されており、最近のエポックは符号付き32ビット範囲内で使えるタイムスタンプの範囲を最大化しました。他のシステムは自分のユースケースに合わせて他のエポックを選びました。NTP(Network Time Protocol、RFC 5905)は1900年1月1日を使用します、NTP がより長い歴史的範囲をカバーする必要があったためです。Windows FILETIME は 100 ナノ秒チック単位のエポックとして 1601年1月1日を使用します(1601 を含む400年のグレゴリオ暦周期の始まり)。VAX/VMS は 1858年11月17日(天文学で人気の修正ユリウス日のエポック)を使用しました。Mac classic は 1904年1月1日を使用しました。JavaScript の Date は Unix エポックを使いますが、秒ではなくミリ秒をカウントします(64ビット浮動小数点で、±1億年の使える範囲)。要点は、Unix エポックが2026年で支配的ですが、歴史には他の多くの選択があり、それぞれに後方互換性のレガシーがあります。

Y2K38 問題、Unix 時間が(ある意味で)期限切れになる

time_t が符号付き32ビット整数(元の Unix 設計)である場合、表現可能な最大タイムスタンプは 2,147,483,647 で、これは 2038年1月19日(火) 03:14:07 UTC に対応します。1秒後、値は負にオーバーフローし、1901年12月13日に巻き戻ります。これが Y2K38 問題(Epochalypse とも呼ばれる)です。現代の64ビットシステムでは、time_t は符号付き64ビット整数で、オーバーフロー日は 292,277,026,596年12月4日、太陽が死んだはるか後です。しかし32ビット組み込みシステムは、産業用 PLC、長期ミッションの衛星、銀行のバックエンド、石油・ガスの SCADA ネットワーク、自動車インフォテインメント、数十年の寿命を持つ IoT センサーなどで現在も活発に展開されています。緩和策は2000年代初頭から進行中です、すべての主要 OS、データベース、言語は今や64ビットハードウェアで64ビット時間をデフォルトとしています(Linux は2020年3月にカーネル 5.6 で移行を完了、Windows は常に64ビットを使用、macOS Catalina は2019年に32ビットサポートを廃止)。組み込みシステムが long tail です。Y2K38 問題は Y2K のような1日の危機ではなく、2038年に近づくにつれて long tail のシステムで発生する小さな故障の連続になるでしょう、Y2K が誰もパッチを当てなかった obscure なシステムで主に現れたのと全く同じです。

ISO 8601、もう1つの標準時間形式

Unix 時間が転送形式である一方、ISO 8601 は人間が読める形式です。元は ISO 8601:1988 で公開され、2000年、2004年、最近では ISO 8601-1:2019 と ISO 8601-2:2019 で改訂された規格は、2026-05-03T14:30:00Z(Z は UTC を意味)や 2026-05-03T14:30:00+01:00(明示的なオフセット付き)のような表現を定義します。「T」は日付と時刻を区切ります、末尾のオフセットはタイムゾーンの曖昧さを解消します。インターネットプロトコルには、RFC 3339(Klyne と Newman、2002)が ISO 8601 のより簡単に解析できる厳密なサブセットを定義します、これは API の JSON レスポンス、ログタイムスタンプ、JWT exp/iat フィールド、OAuth フローで遭遇する形式です。Unix 時間との関係: ISO 8601 は瞬間の人間が読める形式で、Unix 時間は同じ瞬間の整数形式です。このようなコンバーターは双方向で行き来します。ローカル時間形式(オフセットなしの 2026-05-03T14:30:00)は曖昧で、タイムゾーンを横断するシステムでは避けるべきです、JSON API がタイムスタンプを返すと主張しながらどのゾーンにあるかを指定しないという微妙なバグの頻繁な原因です。

秒対ミリ秒、最も一般的な混乱

OS レベルでは、Unix 時間は秒をカウントします、約2001年から2286年の間のあらゆる瞬間に対して10桁の整数(2001年以前のタイムスタンプは9桁以下)。JavaScript の Date.now()、JVM の System.currentTimeMillis()、.NET の DateTimeOffset.ToUnixTimeMilliseconds()、ほとんどの Web API はミリ秒をカウントします、同じ範囲に対して13桁の整数。2つの形式は正確に1,000倍だけ異なり、複数のシステムと話すコードで最も一般的なタイムスタンプ関連バグは、ミリ秒値を秒を期待する関数に渡すこと(予想より1,000倍未来の日付になる)、または逆(エポックから秒の何分の一かの日付になる)です。このコンバーターは桁数で自動検出します、10桁以下 = 秒、13桁以上 = ミリ秒。中間の値(11-12桁、曖昧)では、コンバーターはもっともらしい日付を与える解釈を優先します。マイクロ秒(16桁、一部の高精度システムと多くのデータベース TIMESTAMP 型で使用)とナノ秒(19桁、Linux clock_gettime、Go time.UnixNano()、OpenTelemetry のような現代の可観測性ツールで使用)も発生しますが、ユーザーデータでは一般的ではありません。

タイムスタンプ変換の一般的な用途

• APIデバッグ · APIレスポンスのタイムスタンプを変換して、データがいつ作成または変更されたかを理解します。
• ログ分析 · サーバーとアプリケーションのログのタイムスタンプを読み取って理解します。
• JWT のデバッグ。 JSON Web Token の exp(有効期限)と iat(発行時刻)クレームは RFC 7519 によると Unix 時間整数です。トークンが期限切れかどうかを確認したり、いつ発行されたかを見るには、ここに値を貼り付けます。
• 時間差の計算。 2つの Unix タイムスタンプを引き算して、それらの間の経過時間を秒(またはミリ秒)で取得します。タイムゾーンの計算なし、DST の調整なし、暦算術のエッジケースなし。
• エポック列を持つデータベースクエリ。 多くの古いデータベースはタイムスタンプを Unix 整数として保存します。「X と Y の間のすべてのイベント」をクエリするには、人間が読める境界の日付を WHERE 句のために Unix 整数に変換する必要があります。
• スケジューリングと cron ジョブ。 絶対時刻でジョブをスケジュールするシステム(Kubernetes CronJobs、AWS EventBridge、Azure Logic Apps)はしばしば設定で Unix 時間ターゲットを必要とします。人間が読めるターゲット時間をエポックに変換します。
• 「興味深い」タイムスタンプのデコード。 有名なエポック値:0 = 1970年1月1日 00:00:00 UTC(エポックそのもの);1234567890 = 2009年2月13日 23:31:30 UTC(「Unix billion」瞬間として一時的に祝われた);1500000000 = 2017年7月14日 02:40:00 UTC;2000000000 = 2033年5月18日 03:33:20 UTC;2147483647 = 2038年1月19日 03:14:07 UTC(Y2K38 オーバーフローポイント)。

うるう秒と「真の」時間に関する注意

微妙な複雑さ:POSIX で定義された Unix 時間はうるう秒を含みません。協定世界時(UTC)は地球の実際の自転と civilian 時間を合わせるために、時々うるう秒を加えます、システムが1972年に始まって以来27回のうるう秒が追加されました。Unix 時間はそれらのうるう秒が起きなかったかのように振る舞います、うるう秒が日の終わりに挿入されると、時計は最後の秒を繰り返す(Linux の伝統的な振る舞い)か、より長い期間にわたって広げる(Google の「leap smear」アプローチ、AWS と多くの CDN が採用)かのどちらかです。ほとんどのアプリケーション用途では、これは重要ではありません、サブ秒精度はアプリケーションレベルでめったに重要ではありません。高精度の科学研究、金融取引システムのタイムスタンプ、または法廷で証拠価値のあるタイムスタンプには、うるう秒の振る舞いはエッジケースの既知の原因です。IERS(International Earth Rotation and Reference Systems Service)は6か月前にうるう秒を発表します、最新のものは2016年12月31日の終わりに挿入されました、国際社会はうるう秒を完全に廃止することを検討しました(2035年までに行う決議が2022年の General Conference on Weights and Measures で採択されました)。

プライバシー、ブラウザ内のみで変換

貼り付けるタイムスタンプは通常それ自体としては敏感ではありません(Unix 整数は時間の瞬間しか明らかにしません)、しかしコンテキスト、タイムスタンプの隣に実際のユーザー識別子を含むログ行、実際のユーザーに関するクレームを含む JWT、内部 ID を持つ API レスポンスなど、はしばしば敏感です。このコンバーターは JavaScript 組み込みの Date API を介して完全にブラウザで実行されます。アップロードなし、ログなし、タイムスタンプを入力する間に DevTools の Network タブを確認(リクエストは出ません)するか、読み込み後にページをオフライン(機内モード)にしてください。継続更新の「now」表示はネットワーク時刻ソースではなくローカルクロックを使用します。

よくある質問

Unixタイムスタンプとは?

Unixタイムスタンプ(エポックまたはPOSIX時間とも呼ばれる)は、1970年1月1日午前0時0分0秒UTC以降の秒数(またはミリ秒数)です。これはコンピューティングで時間を表現する標準的な方法です。

秒とミリ秒の違いは?

Unixタイムスタンプは秒(10桁、例: 1711824000)またはミリ秒(13桁、例: 1711824000000)で表すことができます。このツールは入力の長さに基づいて自動的に検出します。

なぜ変換された時間が数時間ずれているのですか?

コンバーターはローカル時間、UTC、ISO 8601形式を表示します。結果が予想された時間と一致しない場合は、タイムゾーンを意識した形式を読んでいることを確認してください(UTCとローカル時間の違い)。

Y2K38 問題とは何ですか?

Unix 時間が符号付き32ビット整数(元の Unix 設計)に格納される場合、2038年1月19日 03:14:07 UTC にオーバーフローします。現代の64ビットシステムは影響を受けません、オーバーフロー日は約2920億年に変わります。Y2K38 リスクは依然として展開中の32ビット組み込みシステム(産業用 PLC、衛星、自動車インフォテインメント、銀行のバックエンド、数十年の寿命を持つ IoT センサー)に集中しています。Y2K と異なり、Y2K38 は1日の危機ではなく、2038年に近づくにつれて long tail のシステムで小さな故障が連続するでしょう。

オフラインで動作しますか?

はい、ページが読み込まれると、すべての変換は JavaScript 組み込みの Date API を介してブラウザで実行されます。使用中のネットワーク呼び出しなし。「Now」ボタンはデバイスのローカルクロックを使用します、上部の継続更新タイムスタンプは時刻サーバーに連絡せずシステムクロックから更新されます。

関連ツール