無料Unixタイムスタンプ変換ツール
Unixタイムスタンプと人間が読める日付を相互に変換します。
タイムスタンプ → 日付
日付 → タイムスタンプ
Unixタイムスタンプとは？
Unixタイムスタンプ（エポック時間またはPOSIX時間とも呼ばれる）は、1970年1月1日00:00:00 UTCからの経過秒数です。タイムゾーンに依存しないシンプルな方法で時点を表現でき、プログラミング、データベース、API、サーバーログで広く使用されています。
例えば、タイムスタンプ1700000000は2023年11月14日22:13:20 UTCを表します。JavaScriptはミリ秒単位のタイムスタンプ（1000倍）を使用しますが、他の多くの言語やAPIは秒単位を使用します。
よくある質問
どのような日付形式を入力できますか？
ほとんどの標準的な形式で日付を入力できます：ISO 8601（2025-12-31T23:59:59Z）、一般的な日付文字列（Dec 31, 2025 11:59 PM）、または2025-12-31 23:59:59のような単純な形式。コンバーターはブラウザ組み込みの日付パーサーを使用します。
秒とミリ秒は自動的に判別されますか？
はい。タイムスタンプが1兆より大きい場合、コンバーターはミリ秒として扱います。それ以外は秒として扱います。両方の形式が結果テーブルに表示されます。
Year 2038問題とは何ですか？
Unixタイムスタンプを32ビット符号付き整数として保存するシステムは、2038年1月19日03:14:07 UTCにオーバーフローします。最新のシステムは64ビット整数を使用しており、数十億年先の日付も表現できます。このツールはJavaScriptのNumber型を使用しており、2038年をはるかに超えるタイムスタンプを扱えます。
なぜ1970年1月1日なのか?
Unixタイムスタンプは、Unixエポック、1970年1月1日(木曜日)00:00:00 UTCからの経過秒数の整数カウントです。これは時間の一瞬を一意に識別する単一のスカラー値で、カレンダーやタイムゾーンに依存せず、東京にいてもトロントにいても、同じ数値が同じ瞬間を表します。
1970年という選択はやや恣意的でしたが、ランダムではありません。UNIX Programmer's Manual初版(1971年11月)では、システム時刻を1971年1月1日からの60Hzのクロックティック数として定義していました。32ビット符号なし整数が60Hzでカウントすると、システムはオーバーフローまで約2.26年しか持たず、この問題はすぐに明らかになりました。1972年に第2版が準備されているとき、Ken ThompsonとDennis Ritchieのチームは1970年1月1日からの秒を数えるように切り替えました:32ビット符号付き整数で秒をカウントすると約68年持ち、コードを書いていたエンジニアの労働寿命を快適に超え、プロジェクト開始前の最近の元日であったため演算が容易でした。委員会投票もIANAスタイルの標準化プロセスもありませんでした。Unixがそれと共に出荷されたため選択が定着し、1億台のマシンがその瞬間からカウントするようになると、代替は実行不可能になりました。
POSIX(1988)は、IEEE Std 1003.1の「Seconds Since the Epoch」として1970年エポックを成文化しました。今日、同じエポックがC/C++のtime_t、Pythonのtime.time()、RubyのTime.now.to_i、JavaScriptとJava(ミリ秒、後述)、Linux/macOSのファイルシステムタイムスタンプ、BitcoinとEthereumのブロックヘッダー、JWTのiat/exp/nbfクレームを支えています。一部のシステムはオフセットエポックを使用します(Windows FILETIMEは1601年1月1日からの100ナノ秒ティックをカウント、.NETのDateTimeは西暦1年1月1日からのティック)が、Unix時間はOSや言語の境界を越えるものすべてのリンガフランカです。
秒 vs ミリ秒、最も一般的なバグ
POSIXはタイムスタンプをエポックからの秒として定義しています。すべてのCライブラリ、すべてのPythonインタープリタ、すべてのRuby/Go/Rust/Elixirランタイムが秒を返します。JavaScriptは有名な例外で、Date.now()とnew Date().getTime()はミリ秒を返します。JavaのSystem.currentTimeMillis()も同じ規約に従い、いくつかの新しいデータベースシステム(例えばMongoDB BSONのDate型)もミリ秒を保存します。
その結果、言語間の永遠のバグが生まれます:Goバックエンドが1700000000(秒)をJSONフィールドに書き込みます。Node.jsクライアントがそれをnew Date(1700000000)に渡しますが、JavaScriptはミリ秒を期待するため、結果の日付は2023年後半ではなく1970年1月20日になります。修正はnew Date(1700000000 * 1000)です。逆に、JSミリ秒タイムスタンプをPythonのdatetime.fromtimestamp()に送ると、年が約55895になります。Stack Overflowには「JavaScript Dateが1970年を表示する」質問のバリエーションが何十もあり、この不一致が圧倒的多数の根本原因です。
このコンバーターはヒューリスティックを実装しています:入力が1,000,000,000,000より大きい場合はミリ秒として扱い、そうでない場合は秒として扱います。これが機能するのは、1e12秒が西暦33658年(実世界の秒スケール入力をはるかに超える)である一方、1e12ミリ秒は2001年9月9日 UTC(現代の範囲内)であるためです。一部の科学システムやLinuxカーネルAPIで使用されるマイクロ秒およびナノ秒のタイムスタンプはしきい値をさらに上げるので、それらについては精度を明示的に指定する必要があります。
2038年問題(「Y2K38」)
32ビット符号付き整数は、−2,147,483,648から+2,147,483,647までの値を保存できます。1970年1月1日 UTCからの秒として解釈すると、表現可能な最大の瞬間は2038年1月19日(火曜日)03:14:07 UTCです。その1秒後、カウンタはオーバーフローして最も負の値にラップし、それは1901年12月13日(金曜日)20:45:52 UTCとしてデコードされます。32ビット幅のtime_t、時間用に4バイト符号付き整数を保存するデータベースカラム、約2010年以前にファームウェアが書かれたあらゆる組み込みシステムがリスクにさらされています。
露出面は不快なものです:今日インストールされた15-30年の展開ライフサイクルを持つ産業用PLCおよびSCADAコントローラー、2038年の境界で飽和することが文書化された古いMySQL TIMESTAMPカラム、ext3ファイルシステム、4バイトタイムスタンプを詰め込むバイナリプロトコル形式(DNSSEC RRSIGフィールド、NTPv3、いくつかの産業用フィールドバス)、静かにインストールされた古い32ビットLinuxカーネルを実行するスマートTVや自動車のインフォテインメント。主流の修正はtime_tを64ビットに拡張することで、これにより最大値が約+2920億年、太陽の熱的死を超える時間まで延長されます。Linux 5.6(2020年3月)はArnd Bergmannのy2038パッチセットを介してすべての32ビットアーキテクチャに64ビット時間syscallを追加しました。glibc 2.34(2021年8月)は_TIME_BITS=64を介して64ビットtime_tをオプトインにしました。Debian 13「Trixie」(2025)はアーカイブ全体が再コンパイルされた最初のリリースです。AppleはmacOS 10.15(2019)とiOS 11(2017)で32ビットバイナリを非推奨にしたため、消費者の機器群は事実上免疫があります。
残るリスク面は圧倒的に組み込みとディスク上のレガシーデータです:64ビットカーネルがレガシーデータベースから32ビットタイムスタンプカラムを読むのは、データベース自体と同じくらい壊れています。マイグレーションはカーネルの問題だけでなく、アプリケーションごとのデータ形式の問題です。
JavaScript Date、この分野で最も呪われたAPI
JavaScriptのDateオブジェクトは、Brendan Eichがオリジナルの LiveScript を書いた10日間のスプリント中、1995年5月にJava 1.0からそのままコピーされました。Java自体はJDK 1.1(1997)でjava.util.Dateのメソッドのほとんどを非推奨にしましたが、JavaScriptはそれらを継承し、Web互換性を壊すことができなかったため、残されました。その結果、次のようなAPIになりました:
- 月は0インデックス(
new Date(2024, 0, 15)= 1月15日)ですが、日は1インデックスです。 getYear()は「年から1900を引いた値」を返し、2024年のgetYear()は124です。getFullYear()は2024を直接返すために後で追加されました。Date.parse('2024-03-15')はUTC真夜中として解析されます。Date.parse('2024/03/15')はローカル真夜中です。Date.parse('March 15, 2024')は実装定義です。- ECMAScript 5(2009年12月)以前は、解析はほぼ完全に実装定義であり、同じ入力文字列がIE、Firefox、Chrome、Safariで異なる
Date値を生成する可能性がありました。
Temporal API(2021年3月からTC39 Stage 3)は現代の代替で、Temporal.Instant、Temporal.PlainDate、Temporal.PlainTime、Temporal.ZonedDateTime、そして本物のTemporal.Duration型を提供します。ブラウザサポートは展開中です(Firefox Nightly、Safari 18部分対応、2024年時点でChromeはフラグの背後)。ポリフィルは動作しますが約25 KB追加します。Moment.jsは2020年9月にメンテナーによってメンテナンスモードに入れられました。2026年の新しいプロジェクトでは、ブラウザサポートが許可すればTemporal優先、それ以外はLuxonまたはdate-fns、Moment.jsは決して、というのが推奨です。
こんなときに使う
- APIレスポンスのデバッグ。ほとんどのJSON APIはタイムスタンプをUnix整数またはISO 8601文字列のいずれかとして返し、多くはそれらを混在させます。1日に数十回コンバーターに数値を貼り付けるのが最高ボリュームのユースケースです。
- ログファイル解析。syslog、journald、AWS CloudWatch、ほとんどのアプリケーションログはUnix秒でタイムスタンプされています。エンジニアはログ行からタイムスタンプをコピーし、壁時計の同等値を知る必要があります。
- データベース日付カラム検査。一回限りの
psqlまたはmysqlクエリが1700000000を返します。データベースにはFROM_UNIXTIME()のような関数がありますが、アドホック作業にはブラウザツールの方が高速です。 - JWT検査。OAuthトークンをデコードすると
"exp": 1738367200と表示されます。このトークンは期限切れですか?いつ期限切れですか?タイムスタンプコンバーターが最速の答えです。 - ブロックチェーンのタイムスタンプ。Bitcoinのブロック
nTimeはUnix秒です(2106年にオーバーフロー、4バイト符号なし)。EthereumブロックのタイムスタンプもUnix秒です。 - OSファイルシステムメタデータ。
ls -l --time-style=+%sはUnixのmtimeを表示します。stat -c '%Y' filenameはmtimeを整数として返します。フォレンジックタイムスタンプの照合は、しばしば手動デコードを伴います。 - 証明書の
notBefore/notAfterとHTTPのIf-Modified-Sinceヘッダー、すべて時折デコードが必要なタイムスタンプです。
うるう秒についての注意
1972年以来、地球の減速する自転に壁時計時間を合わせるために、UTCには27のうるう秒が挿入されてきました。最も最近のものは2016年12月31日 23:59:60 UTCでした。Unix時間はうるう秒をエンコードしません、POSIXはUnixタイムスタンプがすべての日に正確に86,400秒があるふりをすると明示的に述べています。古いLinuxシステムは最後の秒を「繰り返し」ます。GoogleとAWSは、余分な秒を24時間のウィンドウに分散させる「leap smear」を使用します。いずれにせよ、Unix時間はストレージで23:59:60を読むことはなく、うるう秒をまたぐ2つのタイムスタンプの差を取ると、真のSI秒経過時間より1秒短い答えが出ます。アプリケーションコードにとっては不可視です。天文学や金融取引ソフトウェアにとっては重要な場合があります。2022年11月、第27回国際度量衡総会は2035年までにうるう秒の挿入を停止することを投票で決定し、それらをはるかに大きな周期調整で置き換えます。
クイックリファレンス
| Timestamp | UTC datetime | Note |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The epoch |
| 1,000,000,000 | 2001-09-09 01:46:40 | First "billion-second" milestone |
| 1,234,567,890 | 2009-02-13 23:31:30 | "Cool number" celebrated by some devs |
| 1,700,000,000 | 2023-11-14 22:13:20 | |
| 2,000,000,000 | 2033-05-18 03:33:20 | "Two billionth second" |
| 2,147,483,647 | 2038-01-19 03:14:07 | Last second representable in signed 32-bit |
| 4,294,967,295 | 2106-02-07 06:28:15 | Last representable in unsigned 32-bit (Bitcoin's nTime limit) |
| 9,999,999,999 | 2286-11-20 17:46:39 | Last 10-digit timestamp |
その他の質問
なぜ同じタイムスタンプが友人のマシンで異なる時刻を表示するのですか?
基礎となる数値はUTCですが、表示はローカル時刻に変換されるためです。1700000000は22:13:20 UTCですが、ニューヨークでは17:13:20、シドニーでは翌日06:13:20です。数値は同じで、レンダリングだけが異なります。タイムゾーンの混乱を排除するには、両方のマシンにUTCで表示するように頼んでください。
Y2KとY2K38の違いは何ですか?
Y2K(2000年問題)はアプリケーションコードのロジック問題でした:多くのシステムが年を2桁のASCIIで保存していたため、「00」は1900年と2000年の間で曖昧になりました。すべてのアプリケーションを個別に検査してパッチを当てる必要があり、世界全体の修復支出は3000億〜6000億ドルと推定されました。Y2K38は主に低レベルライブラリのデータ型問題であり、Cライブラリとカーネルを64ビットtime_tに対して再コンパイルすることで、それらにリンクするすべてのアプリケーションの大部分の表面が修正されます。残りの難しいケースは、永続化されたディスク上のデータ(データベース、ファイルメタデータ、バイナリプロトコル)で、データ移行ツールが必要です。従来の見方では、2038年は2000年よりも小さく、ニュース価値の低いイベントになるとされています、より局所的な組み込みデバイスの障害、より少ない見出しの停止。
なぜnew Date('2024-03-15')が時々3月14日を表示するのですか?
その文字列がES5標準によりUTC真夜中として解析され、その後ローカルタイムゾーンで表示されるためです。米国太平洋のようなUTC-8ゾーンでは、3月15日のUTC真夜中はローカル時間の3月14日午後4時なので、.getDate()は14を返します。現代のコードでの修正は、new Date('2024-03-15T12:00:00')(Zを省略した場合、JavaScriptはローカル正午として解析します)か、より良いのは、Temporal.PlainDate.from() APIが出荷されたらそれです。
何かがサーバーに送信されますか?
いいえ。変換はブラウザでローカルに実行されるJavaScript算術です。入力したタイムスタンプについて何もページを離れません、顧客ID、内部ログ行、またはどこかにアップロードしたくないセッションデバッグデータである場合に便利です。ページは一度読み込まれるとオフラインで動作します。
関連ツール
オンライン無料単位変換
長さ、重量、温度、データストレージ、速度、時間、および面積の単位を瞬時に変換します。 無料オンライン単位変換、サインアップ不要。
無料の JSON フォーマッタ＆バリデータ・オンライン
JSONのフォーマット、最小化、検証を瞬時に行います。 JSONを貼り付けると、エラーメッセージ付きのフォーマットされた出力が得られます。 無料、サインアップ不要、ブラウザで動作します。
無料Base64エンコーダー＆デコーダーオンライン
テキストをBase64にエンコード、またはBase64をテキストに即座にデコード。ファイルからBase64への変換をサポート。無料、サインアップ不要、ブラウザで実行。