Unixタイムスタンプ & エポック変換 — マルチ精度

無料オンラインUnixタイムスタンプ変換ツール。秒・ミリ秒・マイクロ秒を自動検出し、UTC・ローカル時刻・ISO 8601・相対時間に即座に変換。リアルタイムEpochクロック搭載。登録不要、100%ブラウザ処理でプライバシーも安心。

トラッキングなしブラウザで動作無料

すべての処理はブラウザ内で行われます。データがサーバーに送信されることはありません。

現在のUnixタイムスタンプ

Unixタイムスタンプ

自動秒ミリ秒マイクロ秒

クイックリファレンス

コード例

POSIX準拠と精度の正確性についてレビュー済み — Go Tools エンジニアリングチーム · Mar 25, 2026

当チームはPOSIX（IEEE Std 1003.1）の定義に基づいてタイムスタンプ変換を検証し、秒、ミリ秒、マイクロ秒にわたる精度検出をテストしています。

Unixタイムスタンプ（Epoch時間）とは？

Unixタイムスタンプ（Epoch時間またはPOSIX時間とも呼ばれます）は、1970年1月1日 00:00:00 UTC からの経過秒数であり、事実上すべてのコンピューティングシステムにおける普遍的な時間基準として機能しています。LinuxカーネルやSQLデータベースからJavaScriptエンジンやモバイルOSに至るまで、現代のほぼすべてのプラットフォームがUnixタイムスタンプとして時間を保存・交換しています。

IEEE Std 1003.1（POSIX）では「Unix epoch（1970年1月1日 00:00:00 UTC）はPOSIX時間のゼロポイントとして機能する」と正式に定義されています。この規約は非常に広く採用されており、現在では世界中で機械可読タイムスタンプの事実上の標準となっています。Unixタイムスタンプは、HTTPヘッダー、JWTトークン、そして事実上すべてのREST APIを含む、サーバーサイドシステム、データベース、ネットワークプロトコルの圧倒的多数で使用されています。

Unix epochの1970年1月1日という日付は、任意に選ばれたものではありません。Unixは1960年代後半にBell Labsで開発され、1970年は当時の日付を管理しやすい整数サイズで表現できる、便利で切りの良い起点でした。任意の時点は、このアンカーポイントからの符号付き64ビット整数の秒数として表現できます。Epochより前の日付は負の数で表されます。例えば、1969年12月31日の深夜UTCは-86400（Epochの1日前、つまり86,400秒前）となります。

現代のシステムでは、秒単位より細かい時間精度が必要になることがよくあります。これに対応するため、タイムスタンプは一般にミリ秒（千分の1秒。JavaScriptのDate.now()やJavaのSystem.currentTimeMillis()が返す形式）またはマイクロ秒（百万分の1秒。PostgreSQLなどのデータベースや高頻度取引システムで使用）で表現されます。桁数で精度を識別できます：10桁は秒、13桁はミリ秒、16桁はマイクロ秒を示します。この変換ツールは入力の精度を自動的に検出します。

Unixタイムスタンプが分散コンピューティングの基盤となっている理由は、タイムゾーンに依存せず、（通常の条件下で）単調増加し、整数として簡単にソートできるからです。タイムスタンプとして時間を保存し、表示時にのみ人間が読める形式に変換することは、タイムゾーンバグの全カテゴリを排除するベストプラクティスです。トレードオフは可読性です。1741965432のような生のタイムスタンプは変換ツールなしでは意味が分からず、それがまさにこのツールが提供する機能です。

すべての変換はJavaScript Date APIを使用してブラウザ内で完全に行われます。タイムスタンプ、日付、その他のデータがサーバーに送信されることは一切ありません。このツールは、上部のライブクロックに表示されている現在のEpoch時間を含む、あらゆるUnixタイムスタンプを完全なプライバシーのもとで即座に人間が読める日付に変換します。

タイムスタンプは他の開発者ツールとも密接に関連しています。UUID v1およびv7は識別子内に直接タイムスタンプを埋め込んでおり、タイムスタンプを含むAPIレスポンスはJSONフォーマッターを使用して整形すると確認しやすくなります。Unixタイムスタンプの精度、タイムゾーン、夏時間（DST）の取り扱いについて詳しくは、Unixタイムスタンプ完全ガイドをご覧ください。

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

主な機能

精度の自動検出

タイムスタンプが秒（10桁）、ミリ秒（13桁）、マイクロ秒（16桁）のいずれであるかを自動的に検出します。手動でモードを切り替える必要はありません。

双方向変換

タイムスタンプを人間が読める日付に変換したり、任意の日時を選択して対応するUnixタイムスタンプを3つの精度フォーマットすべてで即座に取得できます。

リアルタイムEpochクロック

現在のUnixタイムスタンプがリアルタイムで刻まれる様子を確認でき、変換や計算の正確な基準点として常に利用できます。

マルチフォーマット出力

すべての変換でUTC時刻、ローカルタイムゾーン、ISO 8601形式、そして人間に分かりやすい相対時間（例：「3日前」）が同時に出力されます。

100%ブラウザ内処理

すべての変換はJavaScript Date APIを使用してブラウザ内で完全に行われます。タイムスタンプ、日付、個人データがサーバーに送信されることは一切ありません。

Unixタイムスタンプと他の日付フォーマットの比較

ISO 8601

2025-03-14T15:37:12Z

人間が読めると同時に辞書順でソート可能。データ交換とAPIの標準形式。人間の可読性が重要な場合はUnixタイムスタンプより推奨されます。

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

人間が読めるがソート不可。主にメールヘッダー（Dateフィールド）で使用されます。ISO 8601やUnixタイムスタンプより冗長です。

人間向け日付

2025年3月14日午後3時37分

エンドユーザーにとって最も読みやすい形式ですが、ソート不可でプログラム的な使用には不適切。UI表示レイヤーに限定して使用するのが最適です。

変換の例

標準Unixタイムスタンプ（秒）

1741965432

2025-03-14T15:37:12Z

10桁の秒単位タイムスタンプ。Unix/Linuxシステム、Unix API、JWTトークン、サーバーログで最も一般的に使用されるフォーマットです。この値は2025年の円周率の日（Pi Day）の15:37:12 UTCに対応しています。

Y2Kタイムスタンプ — 2000年1月1日

946684800

2000-01-01T00:00:00Z

Y2Kの瞬間のUnixタイムスタンプ：Unix epochからちょうど946,684,800秒後です。これは便利な校正値です。この入力に対して変換ツールが2000年1月1日を出力すれば、正しく動作しています。

負のタイムスタンプ（Epoch以前）

-86400

1969-12-31T00:00:00Z

負のUnixタイムスタンプは1970年1月1日より前の日付を表します。-86400はEpochのちょうど1日前（86,400秒前）であり、1969年12月31日の深夜UTCに対応します。すべてのシステムが負のタイムスタンプをサポートしているわけではありませんが、この変換ツールでは正しく処理されます。

ミリ秒タイムスタンプ（13桁）

1741965432000

2025-03-14T15:37:12.000Z

13桁のミリ秒単位タイムスタンプ。JavaScriptのDate.now()、JavaのSystem.currentTimeMillis()、および多くの最新REST APIでネイティブに使用されるフォーマットです。これは最初の例を1000倍したものに相当します。自動検出機能が13桁の長さを認識し、ミリ秒として正しく解析します。

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

1

変換方向を選択

「タイムスタンプ → 日付」を選択してUnixタイムスタンプを人間が読める日付にデコードするか、「日付 → タイムスタンプ」を選択してカレンダーの日時をUnixタイムスタンプに変換します。
2

値を入力

入力フィールドにUnixタイムスタンプ（例：1741965432 または 1741965432000）を貼り付けるか入力します。ツールは秒、ミリ秒、マイクロ秒のいずれかを自動的に識別します。「日付 → タイムスタンプ」の場合は、日付ピッカーを使用して年、月、日、時、分、秒を選択します。
3

変換結果をコピー

UTC、ローカル時刻、ISO 8601、相対時間の結果が即座に表示されます。任意のフォーマットの横にあるコピーボタンをクリックすると、クリップボードに直接コピーされます。

一般的なユースケース

API開発とデバッグ: APIレスポンス、JWTトークンペイロード（iat、exp、nbfクレーム）、Webhookイベントデータ、ログエントリに含まれる不透明なタイムスタンプをデコードします。認証トークンが期限切れかどうか、またはイベントがいつ発生したかを即座に検証できます。
データベースのタイムスタンプ保存とクエリ: データベースクエリの作成、保存されたレコードの検査、またはWHERE句で日付範囲フィルターが正しく指定されているかの検証時に、Unixタイムスタンプと人間が読める日付の間で変換します。
ログファイルの分析と相関: 多くのシステムログやアプリケーションログはイベントをUnixタイムスタンプで記録しています。疑わしいログエントリを人間が読める時刻に変換して、複数のサービス間でイベントを相関付けたり、攻撃ウィンドウを特定したり、エラーが発生した正確な瞬間を特定したりします。
JWTトークンの有効期限検証: JSON Web Tokenはペイロードにiat（発行日時）、exp（有効期限）、nbf（有効開始日時）をUnixタイムスタンプとしてエンコードしています。これらの値を直接貼り付けて、手動でepoch計算をすることなくトークンの有効期間を検証できます。
Cronジョブのスケジューリング: 提案された実行時刻をタイムスタンプに変換して戻すことで、cronジョブのスケジュール、スケジュールされたタスク、時間ベースのトリガーが意図した実行ウィンドウと一致しているかを検証します。
タイムゾーンを跨いだ日付調整: Unixタイムスタンプは本質的にタイムゾーンに依存しません。この変換ツールを使用して、異なるタイムゾーンのチーム間で日付や締め切りを調整する際に共有の基準点を確立し、任意のローカル時刻のUTC相当を確認できます。

技術リファレンス

Unixタイムスタンプの定義: Unixタイムスタンプは、Unix epoch（1970年1月1日 00:00:00 UTC、協定世界時）からの経過秒数の整数値です。この値は観測者のローカルタイムゾーンに関係なく同一であるため、時間の保存と比較においてタイムゾーンに依存しない理想的な表現方法です。
32ビット符号付き整数の最大値: 32ビット符号付き整数の最大値は2,147,483,647です。Unixタイムスタンプとして解釈すると、これは2038年1月19日 03:14:07 UTCに対応します。タイムスタンプを32ビット符号付き整数で保存するシステムは、この瞬間にオーバーフローします。これは2038年問題として知られています。64ビットシステムでは数十億年先の日付まで表現可能です。
JavaScriptはミリ秒を使用: JavaScriptのDate.now()およびnew Date().getTime()は、epochからの秒数ではなくミリ秒数を返します。これにより13桁の数値が生成されます。標準的な秒単位のUnixタイムスタンプに変換するには、1000で割って切り捨てます：Math.floor(Date.now() / 1000)。多くのAPIやツールは秒を期待するため、この変換ステップは重要です。
負のタイムスタンプはEpoch以前の日付を表す: Unixタイムスタンプは1970年1月1日より前の日付を表すために負の値を取ることができます。例えば、-86400は1969年12月31日 00:00:00 UTCを表します。符号付き64ビットタイムスタンプの範囲はEpochの前後約2,920億年に及び、あらゆる実用的な用途に十分対応できます。
Unix時間はうるう秒を考慮しない: Unix時間は1日あたり正確に86,400秒（24時間 x 60分 x 60秒）を前提としています。実際には、UTCを地球の自転と同期させるために、IERSによってうるう秒が時折挿入されます。そのため、Unix時間はTAI（国際原子時）に対して完全に線形ではなく、その差は時間とともに増加します。ほとんどのアプリケーションではこの差異は無関係ですが、精密な計時システムではこれを考慮する必要があります。

タイムスタンプ取り扱いのベストプラクティス

タイムスタンプは常にUTCで保存する: タイムスタンプはUTC（またはUnixタイムスタンプ）で保存し、ローカル時刻への変換は表示レイヤーでのみ行ってください。データベース内でタイムゾーンを混在させることは、特に夏時間の切り替え前後で再現やデバッグが困難なバグの一般的な原因です。
最新のAPIにはミリ秒精度を使用する: 最新のAPI、JavaScript環境、データベースのほとんどは、秒（10桁）ではなくミリ秒（13桁）のタイムスタンプを使用しています。外部システムとの統合時には期待される精度を確認してください。秒が期待される場所にミリ秒のタイムスタンプを渡すと、約11,000年先の未来の日付が生成されます。
2038年問題に注意する: Unixタイムスタンプを32ビット符号付き整数で保存するシステムは、2038年1月19日 03:14:07 UTCにオーバーフローします。レガシーシステムの32ビットタイムスタンプフィールドを監査し、64ビット整数またはISO 8601文字列に移行してください。最新の言語やデータベースのほとんどはデフォルトで64ビットタイムスタンプを使用していますが、組み込みシステム、古いデータベース、ファイルシステムにはまだリスクが残っている可能性があります。
セキュリティにクライアント側のクロックを信頼しない: クライアントデバイスのクロックは、偶発的または悪意を持って任意の値に設定される可能性があります。JWTの有効期限チェック、セッションタイムアウト、レート制限など、セキュリティ上重要なロジックにクライアントが提供するタイムスタンプを使用しないでください。常に信頼できるタイムソースを使用してサーバー側でタイムスタンプを検証してください。
人間が読めるデータ交換にはISO 8601を使用する: ログファイル、設定ファイル、開発者が出力を読む可能性のあるAPIレスポンスなど、機械解析可能かつ人間が読めるタイムスタンプ形式が必要な場合、ISO 8601（例：2025-03-14T15:37:12Z）が最適な選択です。辞書順でソート可能で、曖昧さがなく、事実上すべての最新パーサーでサポートされています。

よくある質問

Unix時間はなぜ1970年1月1日から始まるのですか？

Unix epochの日付である1970年1月1日は、1960年代後半にBell LabsでUnixを開発した開発者たちによって、便利で切りの良い起点として選ばれました。当時、タイムスタンプは32ビット整数で保存されていたため、一般的な日付が適度なサイズの数値に収まるよう、epochは現在に十分近い必要がありました。1970年はシステムの開発開始後の、切りの良い年でした。 1970年1月1日自体に深い技術的意義はありません。これはエンジニアリング上の実用的判断でした。他のシステムは異なるepochを選んでいます：Macintoshクラシックツールボックスは1904年1月1日、Windows NTは1601年1月1日、GPS時間は1980年1月6日から始まります。それぞれがそのシステムの時代と設計上の制約を反映しています。 Unix epochが定着した理由は、Unixがコンピューティングにおける支配的なOSとなり、すべての主要なプログラミング言語、データベース、OSが最終的にUnix時間を機械可読タイムスタンプの普遍的な標準として採用したためです。今日、Unix epochはLinuxカーネルからJavaScriptエンジン、SQLデータベースに至るまで、すべての主要プラットフォームで認識されるコンピューティングにおける事実上の普遍的定数です。この選択には一つのよく知られた結果があります：1970年1月1日より前の日付は負の数で表され、一部の古いシステムではこれを処理できません。歴史的な日付や天文計算には、代替のタイムスタンプ形式が好まれることがあります。しかし、ソフトウェア開発の大多数にとって、Unix epochはすべての関連する日付を快適にカバーしています。

2038年問題とは何ですか？

2038年問題（Y2K38またはEpocalypseとも呼ばれます）は、Unixタイムスタンプを32ビット符号付き整数で保存するシステムに影響するコンピューティング上の問題です。32ビット符号付き整数は-2,147,483,648から2,147,483,647までの値を保持できます。Unixタイムスタンプとして解釈すると、最大値の2,147,483,647は2038年1月19日 03:14:07 UTCに対応します。その1秒後、カウンターはオーバーフローして表現可能な最も負の値にラップアラウンドし、1901年12月13日に対応します。これにより、これらのシステムは将来の日付を遠い過去の日付として解釈してしまいます。影響はタイムスタンプの使用方法によって軽微から壊滅的なものまで様々です。システムが入力検証時に有効な将来の日付を拒否したり、時間に依存するレコードを誤ってソートしたり、証明書やトークンの有効期限を誤って計算したり、オーバーフロー値に遭遇した際に完全にクラッシュする可能性があります。修正方法は単純です：タイムスタンプの保存を64ビット符号付き整数に移行します。64ビットタイムスタンプはepochの前後約2,920億年の日付を表現でき、実用上の懸念をはるかに超えています。最新のOS、プログラミング言語、データベースのほとんどは内部的にすでに64ビットタイムスタンプを使用しています。リスクはレガシーコード、組み込みシステム、本番環境でまだ使用されている32ビットOS、ファイルシステムのメタデータ（FAT32のタイムスタンプフィールドなど）、およびBIGINTではなくINTとして定義されたデータベースカラムにあります。開発者は今すぐシステムを監査すべきです。32ビットから64ビットタイムスタンプへの移行は2038年前に行う必要があり、実際には、長期間のレコード（住宅ローン、インフラ資産、法的文書）を持つシステムは、将来の日付が影響を受けるフィールドに入力されるため、はるかに早くこの問題に遭遇する可能性があります。

秒、ミリ秒、マイクロ秒のタイムスタンプの違いは何ですか？

Unixタイムスタンプには3つの一般的な精度があり、値の桁数で区別されます。 秒（10桁）：オリジナルで最も一般的なUnixタイムスタンプ形式です。1741965432は特定の1秒を表します。使用先：Unix/Linuxのシステムコール（time()）、ほとんどのUnixユーティリティ、JWTトークン（iat、expクレーム）、HTTPヘッダー（Last-Modified）、多くのREST API。現在のタイムスタンプはおよそ10桁の長さです。 ミリ秒（13桁）：千分の1秒の精度。1741965432000は上記と同じ瞬間を1,000倍したものです。使用先：JavaScriptのDate.now()、JavaのSystem.currentTimeMillis()、Node.js、最新のJavaScript/TypeScript API、Redis、多くのデータベースクライアント。JSON APIレスポンスで13桁のタイムスタンプを見た場合、ほぼ確実にミリ秒です。 マイクロ秒（16桁）：百万分の1秒の精度。1741965432000000は同じ瞬間を1,000,000倍したものです。使用先：PostgreSQLのTIMESTAMPおよびTIMESTAMPTZ型、Pythonのtime.time_ns()（ただしナノ秒を返す）、高頻度取引システム、ネットワークパケット解析ツール。最も一般的な間違いは精度の混同です。例えば、秒を期待する関数にミリ秒のタイムスタンプを渡すと、約11,574年先の未来の日付が生成されます。作業しているAPIやシステムのドキュメントで期待される精度を常に確認し、この変換ツールの自動検出をサニティチェックとして使用してください。

Unix時間はうるう秒を考慮しますか？

いいえ。Unix時間はうるう秒を考慮しません。これは精密な計時アプリケーションにおける既知の制限の一つです。うるう秒は、UTCを地球のわずかに不規則な自転と同期させるために、国際地球回転・基準系事業（IERS）によって時折挿入されます（理論的には削除も可能ですが、まだ削除されたことはありません）。2026年現在、1972年の導入以来27回のうるう秒が挿入されています。 Unix時間は1日あたり正確に86,400秒（24 x 60 x 60）の完全に規則的なカレンダーを前提としています。うるう秒が挿入されると、実世界にはUnix時間が無視する1秒が存在します。異なるOSはこれを異なる方法で処理します：Linuxは従来、挿入ポイント前後の期間にクロックをわずかに遅く動作させることでうるう秒を「スメア」（smear）します（Googleのアプローチ、「リープスミアリング」とも呼ばれます）。一部のシステムは23:59:60 UTCで秒を複製し、他のシステムは単に調整をスキップしてクロックをドリフトさせます。ソフトウェアアプリケーションの圧倒的多数（Webサービス、API、データベース、ビジネスロジック）にとって、50年以上にわたって蓄積された約27秒のうるう秒の差異は完全に無関係です。この差は人間向けのアプリケーションでは知覚できません。うるう秒が問題となる場面：GPS同期、天文観測、パケットネットワークタイミングプロトコル（PTP/IEEE 1588）、およびUnixタイムスタンプをTAI（国際原子時）と正確に関連付ける必要があるシステム。アプリケーションがこれらのカテゴリに該当する場合は、うるう秒対応を明示的にサポートする計時ライブラリを使用するか、TAIタイムスタンプを直接使用してください。

Unixタイムスタンプは負の値を取ることができますか？

はい、Unixタイムスタンプは負の値を取ることができ、負のタイムスタンプはUnix epoch（1970年1月1日 00:00:00 UTC）より前の日付を表す正当かつ明確に定義された方法です。 epochより前の各秒はゼロから1ずつ減少します。例えば、-1は1969年12月31日 23:59:59 UTC、-86400は1969年12月31日 00:00:00 UTC（epochのちょうど1日前）、-2208988800は1900年1月1日 00:00:00 UTCを表します。ほとんどの最新のプログラミング言語とOSは負のタイムスタンプをサポートしています。Pythonのdatetime.fromtimestamp(-86400)は正しく1969年12月31日を返します。JavaScriptのnew Date(-86400 * 1000)も同じ日付を正しくレンダリングします。PostgreSQLはタイムスタンプを8バイト整数で保存し、epochの数千年前の日付も正しく処理します。ただし、重要な注意点があります。一部の古いシステム、ライブラリ、データベースドライバーは負のタイムスタンプを正しくサポートしない場合があります。符号なし整数をタイムスタンプに使用する32ビットシステムは、負の値を表現できません。UNSIGNED BIGINTやDATETIME型として定義されたデータベースは、負の値を拒否するか、遠い未来の日付として解釈する可能性があります。歴史的な日付（1970年以前のもの）については、移植性のために負のUnixタイムスタンプに依存するよりも、ISO 8601文字列またはデータベースネイティブの日付型として保存する方が安全な場合が多いです。この変換ツールは負のタイムスタンプを正しく処理し、対応する1970年以前の日付を表示します。

JavaScript、Python、その他の言語で現在のUnixタイムスタンプを取得するには？

現在のUnixタイムスタンプの取得は、すべての主要なプログラミング言語で簡単です。 JavaScript / TypeScript: ```javascript // 秒（ほとんどのAPIがこれを期待） const seconds = Math.floor(Date.now() / 1000); // ミリ秒（JavaScriptネイティブ） const milliseconds = Date.now(); ``` Python: ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` Go: ```go import "time" seconds := time.Now().Unix() // int64 milliseconds := time.Now().UnixMilli() // int64 microseconds := time.Now().UnixMicro() // int64 ``` Java: ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); // または java.time（Java 8+）: long seconds2 = Instant.now().getEpochSecond(); ``` PHP: ```php $seconds = time(); // integer $milliseconds = round(microtime(true) * 1000); ``` Ruby: ```ruby seconds = Time.now.to_i milliseconds = (Time.now.to_f * 1000).to_i ``` Bash / Shell: ```bash date +%s # 秒 date +%s%3N # ミリ秒（GNU date） ``` 最も重要な点は、JavaScriptはネイティブでミリ秒を扱うのに対し、他のほぼすべての言語はデフォルトで秒を扱うということです。使用している精度を常に明示し、統合バグを防ぐためにAPIコントラクトに文書化してください。

Epoch時間を人間が読める日付に変換するには？

Epoch時間（Unixタイムスタンプ）を人間が読める日付に変換するには、3つの簡単な方法があります。 1. このオンライン変換ツールを使用（最速） 上の入力フィールドにEpochタイムスタンプを貼り付けます。ツールは秒、ミリ秒、マイクロ秒のいずれかを自動検出し、UTC、ローカルタイムゾーン、ISO 8601、相対時間の各形式で結果を即座に表示します。コピーをクリックして任意の形式を取得できます。 2. コードを使用 JavaScriptの場合：new Date(1741965432 * 1000).toISOString()は'2025-03-14T15:37:12.000Z'を返します。Pythonの場合：from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)で同じ結果が得られます。JavaScriptはミリ秒を、Pythonは秒を期待することに注意してください。これが変換バグの最も一般的な原因です。 3. コマンドラインを使用 LinuxまたはGNU date搭載のmacOS：date -d @1741965432（Linux）またはdate -r 1741965432（macOS）。Windows PowerShell：[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime。 3つの方法すべてが同じ結果を生成します。ターミナルを開いたりコードを書いたりせずに素早い答えが必要な場合は、上のオンライン変換ツールが最速の選択肢です。

現在のUnixタイムスタンプはいくつですか？

現在のUnixタイムスタンプは、このページ上部のライブクロックに毎秒更新されながら表示されています。Unixタイムスタンプは単に1970年1月1日 00:00:00 UTCからの秒数であり、毎秒正確に1ずつ増加します。現在のタイムスタンプをプログラムで取得するには： - JavaScript: Math.floor(Date.now() / 1000)（秒）または Date.now()（ミリ秒） - Python: import time; int(time.time()) - Bash: date +%s 2026年現在、現在のUnixタイムスタンプは17億台（10桁）です。2033年5月頃に20億に達し、32ビットシステムの最大値（2,147,483,647）は2038年1月19日 03:14:07 UTCに到達します。これがいわゆる2038年問題です。このページをブックマークすれば、現在のEpoch時間にいつでもワンクリックでアクセスできます。

APIレスポンスのタイムスタンプをデバッグするにはどうすればよいですか？

APIレスポンスからタイムスタンプの値（通常は「created_at」や「timestamp」などのJSONフィールドにある10桁または13桁の数値）をコピーします。上の入力フィールドに直接貼り付けると、ツールが秒かミリ秒かを自動検出し、UTC日付、ローカル時刻、ISO 8601形式を即座に表示します。タイムスタンプがJWTトークン内にネストされている場合は、まずJWTペイロード（Base64URLエンコード）をデコードしてiat、exp、nbfフィールドを抽出し、その値をここに貼り付けてください。バッチデバッグの場合は、ブラウザコンソールでコードスニペット new Date(timestamp * 1000).toISOString() を使用すると、開発者ツールを離れることなく複数のタイムスタンプを素早く確認できます。

Python、JavaScript、GoでUnixタイムスタンプを取得する方法は？

JavaScriptでは、秒の場合はMath.floor(Date.now() / 1000)、ミリ秒の場合はDate.now()を使用します。Pythonでは、秒の場合はimport time; int(time.time())、ミリ秒の場合はint(time.time() * 1000)を使用します。Goでは、秒の場合はtime.Now().Unix()、ミリ秒の場合はtime.Now().UnixMilli()、マイクロ秒の場合はtime.Now().UnixMicro()を使用します。JavaScriptはネイティブでミリ秒を扱い、PythonとGoはデフォルトで秒を扱うことを覚えておいてください。これは異なる言語で書かれたシステムを統合する際のタイムスタンプバグの最も一般的な原因です。APIが期待する精度をOpenAPI/Swagger仕様に常に文書化してください。

夏時間の切り替え時にUnixタイムスタンプはどうなりますか？

Unixタイムスタンプは夏時間（DST）の切り替えの影響を全く受けません。なぜなら、UTCに基づいており、UTCはDSTを適用しないからです。ローカルタイムゾーンでクロックが「春に進む」または「秋に戻る」とき、Unixタイムスタンプはギャップや繰り返しなく毎秒正確に1ずつ増加し続けます。これが、ローカル日時文字列ではなくUnixタイムスタンプとして時間を保存する主要な利点の一つです。ただし、DSTの移行中にUnixタイムスタンプをローカル時刻に変換すると、同じローカル時刻が2つの異なるUnixタイムスタンプに対応する場合があります（クロックが繰り返される「秋に戻る」時間帯）。タイムスタンプは常にUTCで保存・比較し、ローカル時刻への変換は表示目的のみで行ってください。

ミリ秒のタイムスタンプを秒に変換するにはどうすればよいですか？

ミリ秒のタイムスタンプを1000で割り、小数部分を切り捨てます。JavaScriptの場合：Math.floor(ms / 1000)。Pythonの場合：ms // 1000（整数除算）。例えば、1741965432000（ミリ秒）は1741965432（秒）になります。ミリ秒のタイムスタンプは13桁、秒のタイムスタンプは10桁の長さで識別できます。このツールは精度を自動検出するため、どちらの形式でも直接貼り付けることができます。逆の変換（秒からミリ秒）は単に1000を掛けるだけです：1741965432 * 1000 = 1741965432000。秒を期待する関数にミリ秒の値を誤って渡さないよう注意してください。結果は約11,574年先の未来の日付になります。