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

秒精度のタイムスタンプ（2026年時点で10桁）は、POSIXシステム、Linuxファイルメタデータ、多くのデータベースで使用される元来のUnix時間標準です。ミリ秒精度のタイムスタンプ（13桁）は、JavaScriptのDate.now()、JavaのSystem.currentTimeMillis()、リクエストタイミング、パフォーマンス測定、イベント順序付けのためにより細かい粒度を必要とする多くのWeb APIで使用されます。マイクロ秒精度のタイムスタンプ（16桁）は、高頻度取引システム、科学データ収集、Pythonのdatetimeオブジェクト（マイクロ秒解像度を持つ）に現れます。重要な実用的区別：約1,750,000,000前後のタイムスタンプを見たら、それは秒です。約1,750,000,000,000前後のタイムスタンプを見たら、それはミリ秒です。識別における1000倍のエラーは、どちらの方向にも56年ずれた日付を生成します。159,362,180,000,000は5044年ではなく、単に159,362,180,000ミリ秒であり、これは約1975年です。当ツールは大きさを検出して正しい除数を自動適用するため、推測する必要は一切ありません。

変換された日付が予想より1時間ずれているように見えるのはなぜですか？

これはほとんどの場合、変換ツールのバグではなく、サマータイム（DST）の問題です。UTCはDSTを採用しない連続的で均一なタイムスケールです。しかし、ローカル時間は春に1時間進み、秋に1時間戻ります。例えば、ニューヨークが7月（EDT = UTC-4）の場合、午後3:00 UTCを表すタイムスタンプは現地時間の午前11:00として表示されます。正午を期待していた場合、夏のオフセット（EDT = UTC-4）ではなく冬のオフセット（EST = UTC-5）を頭の中で適用している可能性があります。変換ツールはUTCとローカル時間の両方を、正確なUTCオフセット（例：UTC-4またはUTC-5）をラベル付けして並べて表示するため、どのオフセットが適用されているかを即座に確認できます。オフセットが現在地に対して間違っている場合は、パソコンのシステムタイムゾーン設定を確認してください。ブラウザベースのツールはオペレーティングシステムからローカルタイムゾーンを取得するため、システムクロックやタイムゾーンが誤って設定されていると、予期しないローカル時間表示が生成されます。

Unixタイムスタンプ変換ツールで1970年より前の日付を変換できますか？

はい。Unixタイムスタンプシステムはエポックより前の日付に対して負の数をサポートします。1970年1月1日 00:00:00 UTCはタイムスタンプ0です。1秒前の1969年12月31日 23:59:59 UTCはタイムスタンプ-1です。1日前（1969年12月31日 00:00:00 UTC）はタイムスタンプ-86400です。当変換ツールは負のタイムスタンプを西暦1000年1月1日（タイムスタンプ-30610224000）まで正しく処理し、ほぼ全ての歴史的コンピューティングデータをカバーします。西暦1000年より前の日付については、予期的グレゴリオ暦（1582年の採用以前にグレゴリオ暦を遡って拡張したもの）が不正確さを増すため、代わりに専門の歴史的日付ライブラリを使用すべきです。1970年以前のタイムスタンプは、系図データベース、歴史的アーカイブ、レガシー銀行システム、Unixエポックが標準化される前に運用されていたシステムからインポートされたデータに最も一般的に現れます。

2038年問題とは何で、心配すべきですか？

2038年問題（Y2038またはY2K38）は、Unixタイムスタンプを符号付き32ビット整数として保存するシステムに影響します。この表現では、最大値は2,147,483,647で、これは2038年1月19日 03:14:07 UTCに対応します。1秒後、値は-2,147,483,648にオーバーフローし、これは1901年12月13日を表します。136年の逆方向ジャンプで、日付計算、比較、表示が壊滅的に失敗します。これはY2Kバグと同じクラスの問題ですが、根本原因が異なります。リスクのあるシステムには以下が含まれます：32ビット組み込みデバイス（ルーター、産業用コントローラー、古いIoTハードウェア）、time_t型を使用する32ビットプラットフォーム向けにコンパイルされたレガシーC/C++プログラム、古いバージョンのPHP（32ビットでは5.6以前）、32ビットMySQL/MariaDBインスタンス。最新のシステム（64ビットLinux、macOS、Windows、全ての主要クラウドプラットフォーム、現在のプログラミング言語ランタイム、最近のデータベースバージョン）のほとんどは64ビットタイムスタンプを使用しており、免疫があります（64ビット符号付きタイムスタンプは西暦292,277,026,596年にオーバーフローします）。インフラを保守している場合は、日付を扱う32ビットシステムを監査し、2038年より前に64ビットへの移行を計画してください。

ISO 8601形式とは何で、なぜAPIの日付に使うべきですか？

ISO 8601は国際標準化機構によって公開された日付と時刻を表現するための国際標準です。形式は次のようになります：2026-05-10T15:30:00Z（UTC）または2026-05-10T15:30:00-04:00（タイムゾーンオフセット付き）。APIレスポンスとデータ交換にとって最良の選択となるいくつかの利点があります。曖昧さがありません。地域形式（05/10/2026はロケールによって5月10日か10月5日か分からない）とは異なり、ISO 8601は常にYYYY-MM-DDの順序に従い、これを逆にする文化はありません。プレーンテキストとしてソート可能です。ISO 8601文字列のアルファベット順ソートは時系列順を生成するため、ログファイルやデータベースインデックスに理想的です。タイムゾーンが明示的です。ZサフィックスはUTCを意味し、-04:00のような数値オフセットはローカル時間の関係を明確に示します。広くサポートされています。JSON Schema、OpenAPI、JavaScriptのDate.parse()、Pythonのdatetime.fromisoformat()、そして全ての主要データベースがISO 8601をネイティブに解析できます。日付と時刻をTで区切り、URLやクエリ文字列でのスペースの曖昧さを回避します。これらの理由から、ほぼ全ての最新のAPIスタイルガイド（Google、Microsoft、Stripe、GitHub）が日時表現にISO 8601を推奨しています。

異なるプログラミング言語はUnixタイムスタンプをどのように扱いますか？注意すべき点は？

異なる言語はタイムスタンプを異なる単位と型で返し、それらを混在させることがバグの一般的な原因です。JavaScriptのDate.now()はミリ秒を数値として返します。秒を期待するシステムにこれを渡すと、日付が1,000倍大きくなります（2026年ではなく50668年）。Pythonのtime.time()はfloatとして秒を返し、整数部分が秒、小数部分がサブ秒精度です。ミリ秒が必要な場合は1,000を掛けて丸めます。JavaのSystem.currentTimeMillis()はミリ秒をlongとして返します。PHPのtime()は秒を整数として返し、microtime()は秒をfloatとして返します。Goのtime.Now().Unix()は秒を返し、time.Now().UnixMilli()はミリ秒を返します。RustのSystemTimeはエポックからのDurationをナノ秒精度で使用します。最も安全なプラクティス：システム間でタイムスタンプを送信する際は、API仕様で単位（秒、ミリ秒、マイクロ秒）を明示的に文書化し、受信タイムスタンプの大きさをチェックして検証します。「秒」のはずのタイムスタンプが13桁の場合、黙って50668年の日付を計算するのではなく、拒否または変換してください。

開発者ツール注目2026-05-10

Unixタイムスタンプ変換ツールの使い方 – エポックから日時へオンライン

コンピューターは「2026年5月10日午後3時30分」を理解しません。コンピューターが理解するのは数字です。具体的には、固定された参照点からの秒数（またはミリ秒数）を数える単一の整数です。その参照点がUnixエポック：1970年1月1日 00:00:00 UTCです。1751500800という数字は人間には何の意味もなしませんが、コンピューターにとってはタイムゾーン、サマータイムのシフト、カレンダーの癖とは無関係に、ある正確な瞬間を曖昧さなく表します。このエレガントなシンプルさが、Unixタイムスタンプがソフトウェアにおいて支配的な時刻表現である理由です。APIレスポンス（created_at: 1751500800）、データベースのタイムスタンプカラム、ログファイル（全行がエポック値で始まる）、認証トークン（JWTのiatとexpクレーム）、そして何かがいつ起こったかを記録する必要があるほぼ全てのシステムに現れます。しかし、本番インシデントのデバッグ、監査ログの読み取り、APIレスポンスに正しい日付が含まれているかの確認が必要になった瞬間、それらの整数タイムスタンプは無意味な数字の壁になります。当サイトの無料タイムスタンプ変換ツールはこの摩擦を即座に排除します。任意のUnixタイムスタンプを貼り付けてください。秒（10桁）、ミリ秒（13桁）、マイクロ秒（16桁）のいずれであっても、ツールは同等の人間が読める日付と時刻をUTCとローカルタイムゾーンの両方で表示します。ISO 8601形式の出力（例：2026-05-10T15:30:00Z）は、あらゆるAPIドキュメント、テストフィクスチャ、データベースクエリにそのまま使えます。逆変換も同様にシンプルです。カレンダーピッカーから日付と時刻を選択すると、対応するUnixタイムスタンプが即座に得られます。全ての計算はサーバー通信ゼロでブラウザ内で行われ、多くの変換ツールが見逃すエッジケースも処理します。1970年以前の日付の負のタイムスタンプ、32ビットシステムの2038年問題、秒・ミリ秒・マイクロ秒精度の自動検出です。

schedule

タイムスタンプコンバーター

無料 · 登録不要

このツールを無料で試す →open_in_new

ステップバイステップガイド

Unixタイムスタンプを貼り付けるか、カレンダーから日付を選択する

タイムスタンプを人間が読める日付に変換するには、整数を入力フィールドに貼り付けます。ツールは数値の大きさに基づいて精度を自動検出します。10桁の数値（2026年時点で約1,000,000,000から2,000,000,000）は秒として扱われ、13桁の数値（約1,700,000,000,000から1,800,000,000,000）はミリ秒として扱われ、16桁の数値はマイクロ秒として扱われます。この自動検出により、「このタイムスタンプは秒かミリ秒か？」という推測作業が不要になります。これは本番システムで数え切れないほどの1000倍のオフセットバグを引き起こしてきた問題です。異常な形式のタイムスタンプ（例：小数点以下にミリ秒を含む秒）がある場合、ツールはそれを正しく解析し、小数点以下の秒を含む正確な時刻を表示します。日付をタイムスタンプに変換するには、日付と時刻のピッカーを使用して西暦1000年1月1日から西暦9999年12月31日までの任意の日付を選択します。日付や時刻を調整すると、同等のUnixタイムスタンプが即座に表示されます。「現在時刻を使用」をクリックしてピッカーを現在の瞬間で埋めることもできます。APIテストリクエスト用のタイムスタンプ生成や、特定のログエントリがどれくらい前に作成されたかを確認するのに便利です。

変換された日付を複数の形式で同時に読む

ツールは変換結果を3つの補完的な形式で表示するため、必要なものを正確に選べます。まず、人間が読める日付と時刻がローカルタイムゾーンで表示されます。例えば「2026年5月10日日曜日午後3:30:00 EDT」のように、UTCオフセットが明確にラベル付けされているため、どのタイムゾーンが表示されているかの曖昧さはありません。次に、UTC同等値がその横に表示されます。UTCはタイムゾーンの混乱を完全に排除する普遍的な参照だからです。並列表示により、タイムスタンプが期待と一致しているかを即座に検証できます。APIがユーザー作成時刻を1751500800と返し、ローカル表示が午後3:30を示しているのにUTCが午後7:30を示している場合、タイムスタンプは正しく、差は単にタイムゾーンオフセットであることが分かります。第三に、ISO 8601形式の文字列が表示されます（例：2026-05-10T15:30:00-04:00またはUTCの場合は2026-05-10T19:30:00Z）。API、データベースクエリ、ドキュメントですぐに使用できます。ISO 8601は日時表現の国際標準であり、曖昧さがなく、プレーンテキストとしてソート可能で、タイムゾーン情報を含むため、データ交換に最も安全な形式です。相対時間の説明（「3時間前」「2日後」「先週の火曜日」）は、暗算なしで即座に人間的なコンテキストを提供します。

好みの形式で出力をコピーするかコードで使用する

各出力形式には専用のコピーボタンがあります。Unixタイムスタンプ（10桁の秒）、ミリ秒タイムスタンプ（13桁）、ISO 8601文字列、または人間が読める日付の横にあるボタンをクリックして、その特定の形式をクリップボードにコピーします。これにより、コード、データベース、ドキュメントが必要とするものを手動で再フォーマットすることなく正確に取得できます。タイムスタンプ変換をワークフローに統合する開発者にとって、このツールはテストデータ生成のクイックリファレンスとして機能します。アプリが30日後のイベントをどのように処理するかテストしたいですか？日付を選び、対応するタイムスタンプをコピーして、テストデータベースに挿入します。JWTトークンのexpクレーム（有効期限）が切れていないか確認する必要がありますか？expタイムスタンプを貼り付けて相対時間表示を確認します。「5分後」と表示されれば、トークンはまだ有効です。ログ分析では、ログファイルから一連のタイムスタンプを貼り付けて、イベントのタイムラインをローカル時間で再構築します。これにより、インシデントを特定のユーザーアクションと関連付けることがはるかに容易になります。このツールは日付関連のコードを書く際にも役立ちます。既知の参照と照らし合わせて出力を手動で検証できるようにすることで、タイムスタンプから日付への変換が正しいことを確認できます。

ヒントとベストプラクティス

check_circle

Unixタイムスタンプ（秒）は2001年9月から約2286年11月まで10桁です（285年の期間をカバー）。ミリ秒タイムスタンプは同期間に13桁で、2286年までそのままです。タイムスタンプが10桁ならほぼ確実に秒、13桁ならミリ秒、16桁ならマイクロ秒です。ツールがこれを自動検出します。

check_circle

JavaScriptのDate.now()はミリ秒精度のタイムスタンプ（13桁）を返します。Pythonのtime.time()は秒精度と小数点以下のマイクロ秒（例：1751500800.123456）を持つfloatを返します。他のシステムと統合する際の1000倍のエラーを避けるために、言語が何を返すかを把握してください。

check_circle

常にUTCでタイムスタンプをデータベースに保存してください。ローカル時間への変換はユーザーに表示するプレゼンテーション層でのみ行います。この単一のプラクティスがタイムゾーン関連の本番バグの大部分を防ぎます。サマータイムの切り替え、タイムゾーンをまたぐユーザーの移動、異なる地理的地域のサーバーも、正規データがUTCであれば全て問題になりません。

check_circle

ISO 8601形式（2026-05-10T15:30:00Z）はAPIレスポンスとデータ交換にとって最も安全な選択です。人間が読め、機械が解析でき、タイムゾーンが明示的で（Z = UTC、または-04:00のようなオフセット）、プレーン文字列として正しくソートされます。JSON SchemaとOpenAPIはどちらも日時フィールドにISO 8601を推奨しています。

check_circle

2038年問題は32ビット符号付き整数タイムスタンプに影響します。2038年1月19日 03:14:07 UTCに、値が2,147,483,647（32ビット符号付き整数の最大値）に達し、負の数にオーバーフローして、日付が1901年12月にジャンプします。最新の64ビットシステムは免疫があります（2920億年先の日付を表現できます）が、組み込みシステム、レガシーデータベース、古いIoTデバイスはまだ32ビットtime_tを使用している可能性があります。32ビットプラットフォームでtime_tを使用するC/C++コードを保守している場合は、2038年より前に64ビットへの移行を計画してください。

check_circle

負のタイムスタンプはUnixエポック（1970年1月1日）より前の日付を表します。例えば、タイムスタンプ-1は1969年12月31日 23:59:59 UTCに対応します。変換ツールは負のタイムスタンプを西暦1000年1月1日まで正しく処理します。これは歴史家、アーキビスト、Unix時代より前のレガシーデータを扱う全ての人にとって有用です。

check_circle

異なるシステムからのタイムスタンプを比較する際は、常に単位を確認してください。あるシステムは秒でログを記録し、別のシステムはミリ秒で記録する可能性があります。1751500800（秒）のタイムスタンプは2026年5月10日ですが、ミリ秒として解釈された1751500800は1970年1月20日に過ぎません。これは56年の差です。変換された日付が大幅に間違っている場合は、最初のデバッグステップとして1000で割るか掛けてください。

check_circle

タイムゾーン変換について：UTCはサマータイムを採用していません。ローカル時間表示が期待より1時間ずれている場合、ほぼ確実にDST効果を見ています。ツールはUTCとローカル時間の両方を並べて表示するため、DST関連の不一致を即座に特定できます。例えば、東部時間は標準時（EST、11月〜3月）ではUTC-5ですが、夏時間（EDT、3月〜11月）ではUTC-4です。

よくある質問

Unixタイムスタンプ（Unix時間、エポック時間、POSIX時間とも呼ばれる）は、1970年1月1日 00:00:00 協定世界時（UTC）——Unixエポック——から経過した秒数です。うるう秒はカウントせず、各日は正確に86,400秒として扱われます。Unixタイムスタンプがコンピューターで時刻を保存・交換する支配的な方法である理由は、いくつかの強力な特性があるからです。わずか4または8バイトのストレージで済む単一の整数であり（「2026-05-10T15:30:00+00:00」のような日付文字列よりはるかに小さい）、タイムゾーンに依存せず（タイムスタンプは世界中どこでも同じ瞬間を表す）、比較が極めて簡単で（早い時刻は小さい数値を持つため、ソートや範囲クエリは単純な比較）、演算が簡単です（86,400を加算して1日進める、2つのタイムスタンプを減算して経過秒数を測定する）。これらの特性により、Unixタイムスタンプはデータベース、APIレスポンス、ログファイル、認証トークン、ファイルシステム、そして日付を効率的に保存、比較、転送する必要があるあらゆるシステムに理想的です。

Unixタイムスタンプはソフトウェアにおける時刻表現のバックボーンですが、信頼性の高い変換ツールなしでは不可解です。当サイトの無料ツールはタイムスタンプと人間が読める日付の間を即座に変換し、秒/ミリ秒/マイクロ秒を自動処理し、結果をUTCとローカルタイムゾーンの両方で表示します。オフラインで動作し、データをプライベートに保ち、アカウント不要です。次のログ分析、APIデバッグセッション、データベースクエリのためにブックマークしてください。今すぐお試しください。任意のUnixタイムスタンプを貼り付けて、正確な日付と時刻を確認してください。

このツールを無料で試す →open_in_new