Unix タイムスタンプを変換する方法

Unixタイムスタンプは、コンピューターが時刻を保存し通信する方法です。1970年1月1日からの秒数を表す単一の数値です。APIレスポンス、データベースレコード、ログファイル、JWTトークンに現れます。1711824000が実際にどんな日付なのかを知る必要があるとき、コンバーターが必要になります。ブラウザベースのコンバーターは計算を瞬時に処理し、両方向(タイムスタンプから日付、日付からタイムスタンプ)に変換できます。

Unixタイムスタンプの見た目

秒とミリ秒の違いは、末尾の3つのゼロです。10桁の数値は秒、13桁はミリ秒です。2024年時点で、秒ベースのUnixタイムスタンプはすべて10桁であり、2286年11月までそうあり続けます。

タイムスタンプを変換する手順

1. タイムスタンプまたは日付を入力: Unixタイムスタンプを貼り付けて読める日付に変換するか、日付を入力してタイムスタンプを取得します。
2. フォーマットを確認: コンバーターは数値の桁数に基づいて秒とミリ秒を自動検出します。
3. 結果を読む: ローカルタイムゾーン、UTC、ISO 8601フォーマットでの日付を表示します。

Unix時間の簡単な歴史

Unix時間は、1971年11月にBell Labsで発行されたUnix Programmer's Manualで初めて定義されました。元のエポックは1971年1月1日でしたが、間もなく1970年1月1日に変更され、POSIX.1(1988年)で標準化されました。

1970年の選択は恣意的ですが現実的でした。Unixは1969年から1971年に開発され、OSの誕生近くでカウントを始めるのは理にかなっていました。1970年からの秒数を数える32ビット符号付き整数は、1901年12月から2038年1月までの範囲を提供しました。設計者は十分だろうと考えていました。

そうではありませんでした。「2038年問題」(Y2K38とも呼ばれる)は、32ビット符号付きUnixタイムスタンプがオーバーフローする瞬間です。エポックから2147483647秒後、次の刻みは負の数に折り返し、システムはそれを1901年12月と解釈します。ほとんどのモダンシステムは2000年代と2010年代に64ビット整数タイムスタンプに移行しましたが、一部の組み込み機器、古いデータベース、レガシーファイル形式はまだ32ビット時間を使い、2038年前にパッチが必要です。

Unix時間は現在、コンピューターシステムで時刻を表現する事実上の標準です。JSON API、データベース行のタイムスタンプ、JWTの有効期限、ブロックチェーンのブロック時刻、IoTセンサーの読み取り値。ほぼすべてがUnixエポックを直接または間接的に使います。

秒、ミリ秒、マイクロ秒、ナノ秒

システムによって精度が異なります:

• 秒(2024年では10桁): 古典的なUnix時間、POSIX標準、ほとんどのAPIとデータベース
• ミリ秒(13桁): JavaScript Date、Java System.currentTimeMillis()、多くのWeb API
• マイクロ秒(16桁): PostgreSQL timestamp、Python datetime(変換後)
• ナノ秒(19桁): Go time.UnixNano()、eBPFトレース、高頻度取引システム

19桁のタイムスタンプは、ミリ秒を期待するコンバーターを混乱させる可能性があります。異常な数値を見たらソースドキュメントを再確認してください。

タイムスタンプに出会う場所

• APIレスポンス: ほとんどのREST APIは日付をUnixタイムスタンプとして返します: "created_at": 1711824000
• JWTトークン: iat(発行日時)とexp(有効期限)クレームはUnixタイムスタンプです
• データベースレコード: 多くのデータベースは効率的なソートと比較のためにタイムスタンプを整数として保存します
• ログファイル: サーバーログはしばしばエントリの先頭にエポックタイムスタンプを付けます
• Cronジョブ: スケジューリングシステムはUnix形式で時刻を参照します
• ファイルシステムのmtime / atime / ctime: LinuxとmacOSのファイルメタデータはUnix時間を使います
• ブロックチェーンのブロックタイムスタンプ: BitcoinとEthereumのすべてのブロックはヘッダーにUnixタイムスタンプを持ちます
• クッキーとHTTPヘッダー: Max-Age、If-Modified-Sinceはしばしばエポック演算を間接的に使います

コード内のタイムスタンプ

一般的な言語での素早い変換:

JavaScript:

new Date(1711824000 * 1000)            // 秒から(1000を掛ける)
new Date(1711824000000)                // ミリ秒から
Math.floor(Date.now() / 1000)          // 現在の秒数
Date.now()                             // 現在のミリ秒

Python:

from datetime import datetime, timezone
datetime.fromtimestamp(1711824000, tz=timezone.utc)
datetime.now(timezone.utc).timestamp()  # 現在の秒数(浮動小数点)

Bash:

date -u -d @1711824000                 # GNU date(Linux)
date -u -r 1711824000                  # BSD date(macOS)
date +%s                               # 現在の秒数

SQL(PostgreSQL):

SELECT TO_TIMESTAMP(1711824000);       -- エポックをタイムスタンプに変換
SELECT EXTRACT(EPOCH FROM NOW());      -- 現在のエポック

Go:

time.Unix(1711824000, 0)               // 秒から
time.Now().Unix()                      // 現在の秒数

タイムゾーンの扱い

ここはほとんどのタイムスタンプバグが潜む場所です:

• UnixタイムスタンプはつねにUTCです。「ローカル時間」のUnixタイムスタンプは存在しません。数値自体が絶対的です。
• 表示タイムゾーンが重要です。同じタイムスタンプ1711824000はこう表示されます:
  • 2024-03-31 00:00:00 UTC
  • 2024-03-30 17:00:00 PDT(Los Angeles、UTC-7)
  • 2024-03-31 09:00:00 JST(Tokyo、UTC+9)
• DST(夏時間)の遷移は厄介です。「2024-03-10 02:30:00 EST」のようなローカル時刻は存在しません(時計が02:00から03:00へスキップ)。コンバーターは異なる扱いをします。エラーを返すもの、03:30に丸めるもの、標準時刻にシフトするものなど。
• うるう秒は無視される: Unix時間はすべての分が正確に60秒であるかのように扱います。実際のUTCは時折うるう秒を挿入します(最後は2016年)。99%の用途では問題ありませんが、精密天文学や原子時計には重要です。

APIでタイムスタンプを送るときは、つねにUTC秒を使います。ユーザーに表示するときは、彼らのローカルタイムゾーンに変換します。コンバーターは両方向を扱います。

よくある落とし穴

• JavaScript のDate()コンストラクタは秒ではなくミリ秒を取る: タイムスタンプバグの第1位。new Date(1711824000)はその数値をミリ秒として読むため、1970年1月20日と解釈します。new Date(1711824000 * 1000)が必要です。
• Unix時間とExcel/Google Sheetsの日付数値を混同する: Excelは異なるエポック(1899年12月30日)を使い、秒ではなく日数を数えます。Unixタイムスタンプを日付列にインポートすると、間違った日付が表示されます。
• 負のタイムスタンプ: 1970年1月1日より前の日付は負のUnixタイムスタンプとして表現されます。一部のコンバーターやデータベースはこれを拒否し、他は正しく扱います。
• レガシーコードでの2038年: 32ビット符号付き整数タイムスタンプは2038年1月19日03:14:07 UTCにオーバーフローします。ほとんどのモダンシステムは64ビットを使いますが、組み込み機器、古いSQLiteデータベース、32ビットOSを確認してください。
• ロケール依存の日付パース: 「03/04/2024」は米国英語では3月4日、英国英語では4月3日です。システム間ではつねにタイムスタンプ(またはISO 8601文字列)を渡し、ロケール形式の文字列は絶対に渡さないでください。
• サブ秒精度の損失: 秒精度のフィールドにミリ秒タイムスタンプを保存すると、末尾の3桁を失います。一部のAPIは両形式(created_atは秒、created_at_msはミリ秒)を返してこれを回避します。

使いこなしのヒント

• JavaScriptには1000を掛ける: JSのDateはミリ秒を期待しますが、ほとんどのAPIは秒を返します。掛けるのを忘れることが、最もよくあるタイムスタンプバグです。
• つねにUTCを指定する: 変換するとき、タイムゾーンについて明示的になります。「3月31日午前0時」は、UTC、EST、PSTのどれを意味するかでタイムスタンプが変わります。
• 表示にはISO 8601を使う: 変換後、タイムゾーンをまたいだ曖昧さのない通信のために、日付を2024-03-31T00:00:00Zとして整形します。
• コンバーターをブックマークする: APIやデータベースで作業する場合、ワンクリックで使いたくなるほど頻繁にタイムスタンプを変換します。
• 往復で検証する: 疑わしいとき、タイムスタンプを日付に変換し、日付をタイムスタンプに戻します。同じ数値が得られれば、理解は正しいです。
• 桁数に注意する: 10 = 秒、13 = ミリ秒、16 = マイクロ秒、19 = ナノ秒。計算が1000倍または1000000倍ずれていたら、精度の不一致があります。

プライバシー

Unixタイムスタンプコンバーターは完全にブラウザ内で動作します。入力したタイムスタンプと日付はデバイスを離れません。これは、タイムスタンプが機密になりうるからです。内部インフラのタイミングを露呈するログファイルから来たもの、埋め込みユーザー/セッション情報を含むJWTトークン、第三者と共有すべきでない内部API デバッグなど。クラウドのタイムスタンプコンバーターは「改善」目的で入力をログに記録するかもしれません。ブラウザ専用のコンバーターは露出ゼロです。

ブラウザベースの変換は、ページを一度読み込めばオフラインでも動作し、タイムスタンプをフィールドに入れて同じ瞬間に日付を見られるほど高速です。