Unixタイムスタンプ（UNIX時間）と日時を相互に変換できる無料ツールです。 10桁・13桁の自動判別、JSTとUTCの同時表示、ISO 8601形式や曜日の確認、コードスニペットの生成に対応しています。
ミリ秒：-------------
現在日時（JST）
--------- --:--:--
変換フォーム
コードスニペット
new Date(0 * 1000).toISOString()new Date(0).toISOString()datetime.fromtimestamp(0, tz=timezone.utc)date('Y-m-d H:i:s', 0);time.Unix(0, 0).UTC()Instant.ofEpochSecond(0L)SELECT FROM_UNIXTIME(0);date -d @0よく調べられる値
変換履歴
入力欄から離れると、変換した値がここに残ります。
豆知識
Unix時間は1970年1月1日0時（UTC）からの経過秒数です。10桁なら秒、13桁ならミリ秒として自動判定します。JSTはUTCより9時間進んでいるため、同じ数値でも表示は9時間ずれます。
入力した数値や日時はすべてブラウザ内だけで処理され、外部に送信・保存されることはありません。日時の計算はUTC基準で行っているため、お使いの端末のタイムゾーン設定に結果が左右されません。
Unixタイムスタンプとは？秒・ミリ秒とJST/UTCの関係をわかりやすく解説
Unixタイムスタンプ（UNIX時間・エポック秒）とは、1970年1月1日0時0分0秒（UTC）からの経過秒数で時刻を表す方式です。サーバーログやデータベース、APIのレスポンスで「1700000000」のような数値として現れるため、日時に変換して読み解く場面が頻繁に発生します。
本ツールは、この数値と人間が読みやすい日時をリアルタイムで相互変換するオンラインツールです。10桁（秒）と13桁（ミリ秒）を桁数から自動判別し、日本時間（JST）と協定世界時（UTC）を同時に表示するため、9時間の時差を取り違える事故を防げます。
あわせて、ISO 8601形式・曜日・年間通算日・週番号・うるう年判定・現在からの相対時間を表示し、2038年問題の限界値（2147483647）を超えた場合は警告を出します。JavaScript・Python・PHP・Go・Java・MySQL・シェル向けのコードスニペットや、変換結果の共有URLも生成できます。
こんなシーンで便利です
ログに出てきた数値が何日か即座に知りたいとき
「1700000000」のような数値を貼り付けるだけで、JSTとUTCの日時が同時に表示されます。曜日や現在からの相対時間も確認でき、障害発生時刻の把握がすぐに終わります。
システムログやデータベースの解析
サーバーログに記録された数値の羅列を具体的な日時に変換し、障害調査や分析をスムーズに進められます。ミリ秒単位の高精度ログにも対応しています。
API開発・テストの検証
APIのレスポンスに含まれるタイムスタンプが正しい日時を指しているか確認したり、テスト用の値を生成したい時に最適です。「24時間後」「30日後」などのクイック入力も用意しています。
UTCとJSTのズレを確認したいとき
クラウドサーバーのログはUTC、社内の報告はJSTというケースで、同じ数値が両方のタイムゾーンで何時になるかを並べて確認できます。
プログラム用スニペットの作成
JavaScript・Python・PHP・Go・Java・MySQL・シェルなど、指定した日時をタイムスタンプとして扱うコードをすぐに取得できます。
キャッシュ・有効期限の計算
Cookieの有効期限やトークンの失効時刻に使うUnix時間を手軽に算出できます。現在時刻からの加算プリセットで、期限値をワンタップで生成できます。
使い方は簡単 4ステップ
- 数値を日時に変えたい場合は、上の入力欄にタイムスタンプを貼り付けます。カンマ区切りのままでも解釈します。
- 日時を数値に変えたい場合は、下の入力欄に「2025-01-01 00:00:00」のような形式で入力します。
- 必要に応じてJST/UTCの切り替えや、秒・ミリ秒の明示指定を行います。
- 変換結果からJST・UTC・ISO 8601・曜日などを確認し、必要な値をワンクリックでコピーします。
※入力と同時に変換が走り、コードスニペットも自動で更新されます。URLに「?t=1700000000」を付けて開くと、その値を指定した状態で表示できます。
ご利用時の注意点
- 秒とミリ秒の自動判別：入力値が12桁以上ならミリ秒、それ未満なら秒として解釈します。判定結果は入力欄の下に表示され、手動での切り替えも可能です。
- タイムゾーンの扱い：日時の計算はすべてUTC基準で行い、JSTは固定で+9時間として加算しています。そのため、お使いの端末やブラウザのタイムゾーン設定に結果が左右されません。
- 対応範囲：西暦1000年〜9999年相当の範囲に対応しています。範囲外の値や数値以外の文字を入力した場合はエラーを表示します。
- 日本は現在サマータイム（夏時間）を採用していないため、JSTは年間を通じて常にUTC+9です。
- 2038年問題：32ビット符号付き整数の上限である2147483647を超える値を入力すると、警告を表示します。
主要な日時のUnixタイムスタンプ早見表（JST）
システム設計やテストデータ作成に便利な、主要な日時のタイムスタンプ一覧です。よく検索される数値もあわせて掲載しています。
| 日時 (JST) | 10桁 (秒) | 13桁 (ミリ秒) | 備考 |
|---|---|---|---|
| 1970-01-01 09:00:00 | 0 | 0 | Unix時間の起点（UTCでは1970-01-01 00:00:00） |
| 2001-09-09 10:46:40 | 1000000000 | 1000000000000 | 10桁になった瞬間 |
| 2023-11-15 07:13:20 | 1700000000 | 1700000000000 | よく検索される値 |
| 2025-01-01 00:00:00 | 1735657200 | 1735657200000 | 2025年の始まり |
| 2026-01-01 00:00:00 | 1767193200 | 1767193200000 | 2026年の始まり |
| 2027-01-01 00:00:00 | 1798729200 | 1798729200000 | 2027年の始まり |
| 2030-01-01 00:00:00 | 1893423600 | 1893423600000 | 2030年の始まり |
| 2033-05-18 12:33:20 | 2000000000 | 2000000000000 | 20億秒の到達点 |
| 2038-01-19 12:14:07 | 2147483647 | 2147483647000 | 2038年問題の限界値 |
| 9999-12-31 23:59:59 | 253402268399 | 253402268399000 | 最大級の日時表示 |
プログラミング言語別の現在時刻取得
- JavaScript:
Math.floor(Date.now() / 1000) - Python:
import time; int(time.time()) - PHP:
time(); - Go:
time.Now().Unix() - MySQL:
SELECT UNIX_TIMESTAMP();
Unixタイムスタンプの桁数について
10桁（秒単位）: 最も一般的な形式です。2001年9月から2286年までの日時は10桁で表されます。
13桁（ミリ秒単位）: JavaScriptのDate.now()やJavaシステム、高精度なログ解析で利用されます。数値としては秒の1,000倍になります。
16桁（マイクロ秒）: Pythonの一部ライブラリや分散トレーシングで使われることがあります。
※JSTとUTCの差は常に9時間です。同じタイムスタンプでも、JSTで「2023-11-15 07:13:20」の値はUTCでは「2023-11-14 22:13:20」となり、日付が前日にずれる点に注意してください。ログ解析やAPIの不具合調査、データベース（MySQL、PostgreSQL等）の数値確認にぜひお役立てください。
分散システムや大規模データ分析で求められるタイムスタンプ運用の実践アーキテクチャ
単一の数値変換にとどまらず、ビッグデータ基盤やマイクロサービスにおいてタイムスタンプを破綻なく運用するための技術的アプローチを解説します。
秒とミリ秒の混在がバグを生む典型パターンと見分け方
同じ「タイムスタンプ」という名前でも、秒単位とミリ秒単位が混在すると、1000倍のズレが発生します。
見分け方の目安として、10桁なら秒（2001年〜2286年）、13桁ならミリ秒と覚えておくと実務では十分です。ミリ秒の値を秒として解釈すると西暦5万年台、秒の値をミリ秒として解釈すると1970年1月中の日時になるため、変換結果が明らかにおかしい場合はまず桁数を疑ってください。
分散データベースにおける高解像度タイムスタンプの衝突回避
分散環境（Apache Cassandra、Spanner、DynamoDB等）において、ミリ秒やマイクロ秒のタイムスタンプをそのまま主キーやシャードキーに割り当てると、書き込みが特定ノードに集中するホットスポット現象やデータ衝突が発生します。
これを防ぐには、タイムスタンプの前に一意のノードIDやユーザーIDのハッシュ値をプレフィックスとして結合し、データをクラスタ全体に均等に分散させる設計が定石です。
データウェアハウスでの日時クエリ高速化とパーティショニング
BigQueryやSnowflakeなどで数億件規模のログから特定期間を抽出する際、文字列型のタイムスタンプで比較演算を行うとフルスキャンを誘発し、コストと処理時間が肥大化します。
数値型（BIGINT）のUnix時間で日付単位または時間単位のパーティションを構築することで、データ走査量を最小限に抑え、集計クエリのレスポンスを大幅に改善できます。
分散トレーシングにおけるクロックドリフト対策
コンテナ環境や複数のマイクロサービス間でリクエストの処理順序を正確に追跡する場合、各サーバーの内部時計が微妙にズレるクロックドリフトが重大なバグの原因となります。
NTPによる同期に加え、OpenTelemetryなどでリクエストヘッダーに親スパンのタイムスタンプを引き継がせ、相対的な親子関係を明示的にマッピングすることで、物理的なミリ秒の狂いに左右されない分散ログ解析を確立できます。
ログの保存はUTC、表示はJSTという原則
タイムゾーンの取り違えを根本的に防ぐ方法は、保存と計算はすべてUTC（またはUnix時間そのもの）で行い、表示の直前にだけJSTへ変換するという原則を徹底することです。
Unix時間はそもそもタイムゾーンを持たない絶対時刻なので、数値のまま保持している限りズレは発生しません。ズレが生まれるのは、文字列の日時に変換した瞬間です。本ツールがJSTとUTCを同時に表示しているのも、この境界を可視化するためです。
サマータイムを持つ地域を扱う場合の注意点
日本にはサマータイムがないためJSTは常にUTC+9ですが、米国や欧州のタイムゾーンでは年2回オフセットが変わります。
そのため、海外を含むシステムでは固定のオフセット（+09:00など）ではなく、タイムゾーン名（Asia/Tokyo、America/New_York）で保持するのが安全です。特に「毎日9時に実行」といったスケジュールは、オフセットで固定すると夏時間の切り替え時に1時間ずれます。
よくある失敗と対策
10桁（秒）と13桁（ミリ秒）の桁数判定ミスによるデータ登録・取得バグ
JavaScriptのDate.now()などから取得した13桁のミリ秒タイムスタンプを、10桁（秒単位）のみを想定しているバックエンドのAPIやデータベース（MySQLのFROM_UNIXTIMEなど）にそのまま渡してしまい、異常な日時として登録・パースされる典型的な設計ミスです。
💡 対策・解決策を見る▼
JST（日本標準時）とUTC（世界協定時）の9時間差の考慮漏れ
クラウドサーバーやLinuxのシステムログにUTCで出力されたUnix時間を、JSTベースの数値として誤って変換してしまい、障害発生時刻の解析が9時間ズレた状態で進んでしまう失敗パターンです。特に深夜帯のログでは日付まで変わります。
💡 対策・解決策を見る▼
2038年問題（32ビット整数オーバーフロー）の限界値検証の失念
32bitの符号付き整数でUnix timeを管理している古いプログラムにおいて、2147483647（2038年1月19日）を超える未来のタイムスタンプを入力した際の動作テストを行わず、システムが1901年に巻き戻る、あるいはクラッシュするバグを検知できない失敗です。
💡 対策・解決策を見る▼
ブラウザやサーバーのローカルタイムゾーンに依存した誤変換
日時からタイムスタンプへ変換する際、実行環境（クライアントのブラウザ設定やOSの地域設定）への依存に気付かず、意図しないオフセットが加算された値を発行し、APIサーバーとの整合性が破綻するトラブルです。
💡 対策・解決策を見る▼
存在しない日付を入力してしまい、勝手に翌月へ繰り上がる
「2025-02-30」のような存在しない日付を扱うと、多くの言語では自動的に3月2日へ繰り上げられ、誤った日付のまま処理が進んでしまいます。入力フォームの検証漏れで起きやすい失敗です。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.1700000000のようなタイムスタンプは何年何月何日ですか
A. 1700000000は日本時間で2023年11月15日 07時13分20秒（UTCでは2023年11月14日 22時13分20秒）です。本ツールの入力欄に数値を貼り付けると、JSTとUTCの日時が同時に表示され、曜日・ISO 8601形式・現在からの相対時間もあわせて確認できます。サイドバーの「よく調べられる値」からワンタップで入力することもできます。
Q.10桁の秒単位と13桁のミリ秒単位はどのように切り替えて変換しますか
A. 初期設定では桁数から自動判別します。12桁以上であればミリ秒、それ未満であれば秒として解釈し、どちらとして扱ったかを入力欄の下に表示します。自動判別の結果が意図と異なる場合は、「秒」「ミリ秒」ボタンで明示的に指定できます。カンマ区切り（1,700,000,000）で貼り付けた場合も正しく解釈します。
Q.タイムスタンプをJSTとUTCの両方で同時に確認できますか
A. できます。変換結果には日本時間（JST / UTC+9）と協定世界時（UTC）が並べて表示され、それぞれの曜日も確認できます。上部のJST/UTC切り替えは、メインの結果表示と日時入力欄をどちらの基準で扱うかの指定です。サーバーログがUTC、社内資料がJSTといった場面で、9時間の差を取り違える事故を防げます。
Q.日時の入力欄にはどのようなフォーマットで入力すればよいですか
A. 「2025-01-01 00:00:00」「2025/01/01 09:30」「2025年1月1日 12:00:00」のような形式に対応しています。時刻を省略すると0時0分0秒として扱います。入力した日時は、選択しているタイムゾーン（JSTまたはUTC）の時刻として解釈されるため、お使いの端末のタイムゾーン設定に結果が左右されません。2月30日のような存在しない日付はエラーとして表示します。
Q.変換結果を他の人と共有することはできますか
A. できます。変換結果の下にある「この変換結果の共有URLをコピー」を押すと、タイムスタンプとタイムゾーンを含んだURLがコピーされます。そのURLを開くと同じ変換結果が再現されるため、障害調査のログ共有やレビュー時のやり取りに便利です。
Q.変換結果と同時に表示される相対時間とはどのような機能ですか
A. 入力されたタイムスタンプが、現在時刻から数えてどのくらい過去または未来であるかを示す機能です。「3日前」「約2ヶ月後」といった形式で表示されるため、ログの鮮度やキャッシュの有効期限が妥当かどうかを一目で判断できます。
Q.2038年問題のテストに使う限界値のタイムスタンプを確認することはできますか
A. はい、可能です。サイドバーの「よく調べられる値」に32ビット符号付き整数の上限である2147483647（日本時間で2038年1月19日 12時14分07秒）を用意しています。また、この値を超えるタイムスタンプを入力した場合は、レガシー環境で正しく扱えない可能性がある旨の警告を自動表示します。
Q.曜日や週番号、年間通算日も確認できますか
A. できます。変換結果の詳細欄に、曜日・年始からの通算日数・ISO 8601の週番号・うるう年かどうかをまとめて表示します。バッチ処理の実行曜日の確認や、週次集計の境界を調べる際にご利用ください。
Q.変換した値をプログラムで扱うためのコードは取得できますか
A. JavaScript（秒・ミリ秒）、Python、PHP、Go、Java、MySQL、シェルコマンドの7種類・8パターンのコードスニペットを自動生成し、それぞれワンクリックでコピーできます。入力値が空の場合は現在時刻を使ったコードが表示されます。
Q.入力したタイムスタンプや日時データが外部に漏洩することはありますか
A. ありません。本ツールはすべての変換処理をユーザーのブラウザ内だけで行う完全ローカル処理型の安全設計です。入力された数値や日時データが外部のサーバーへ送信されたりデータベースに保存されたりすることは一切ないため、機密性の高いシステムログや開発中のデータでも安心してご利用いただけます。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。