タイムスタンプ変換
Unixタイムスタンプを読める日付に、またその逆に変換します。秒・ミリ秒・ISO 8601・UTC・ローカル時刻・曜日・RFC
Unixタイムスタンプと読める日時の間を、双方向かつ秒とミリ秒の両方で変換します。1735689600または2026-01-01T00:00:00Zを貼り付けると、UTC、お使いのタイムゾーン、そしてISO 8601やRFC 2822などの一般的な形式での相当値が表示されます。
ログを読むとき、エポック秒を返すAPIをデバッグするとき、トークンの有効期限が想定どおりかを確認するときなど、頻繁に必要になります。変換は正確で端末内で実行され、値が秒ではなくミリ秒のように見える場合には警告が表示されます。
Unixタイムスタンプを変換する方法
タイムスタンプまたは日時を貼り付けます
UTCとローカル時刻に変換された値を確認します
必要な形式をコピーします
よくある質問
秒ですか、それともミリ秒ですか？
10桁なら通常は秒、13桁なら通常はミリ秒です。ツールが単位を推測し、結果がおかしい場合には切り替えられます。
Unixエポックとは何ですか？
1970年1月1日00:00:00 UTCからの秒数で、うるう秒は数えません。ある時点を保存する標準的な方法です。
どのタイムゾーンが使われますか？
UTCとブラウザのローカルタイムゾーンの両方が表示されるので、サーバーのログと時計で見ている時刻を比べられます。
1970年より前の日付も扱えますか？
はい。負の値はエポックより前の日付を表し、遠い未来の日付もJavaScriptの日付範囲の限界まで対応します。
日付からタイムスタンプを求められますか？
はい。変換は双方向なので、日付を入力すればエポック値が得られます。
何かアップロードされますか？
いいえ。変換は端末内の計算だけで完結します。
概要
| 入力 | テキスト |
|---|---|
| 複数ファイル | いいえ |
| 実行場所 | ブラウザ内で実行 - ファイルはアップロードされません |
| オフラインでも動作 | はい — ページを読み込んだ後 |
| 料金 | 無料・登録不要・透かしなし |
変換が静かに壊れるところ
変換のバグの多くは構文ではなく意味の問題です。郵便番号のCSV列は、表計算ソフトが数値だと推測した瞬間に先頭のゼロを失います。長いIDは浮動小数点の精度を超えてしまいます。日付は、日が先か月が先かによって意味が変わります。JSONのキーには順序がありませんが、配列にはあります。キーを並べ替えるツールは何も変えませんが、配列を並べ替えるツールはデータを変えてしまいます。Unicodeも落とし穴です。テキストはUTF-8やUTF-16、あるいはBOM付きで届くことがあり、推測を誤ったデコーダーはアクセント付きの文字を文字化けに変えてしまいます。変換を信用する前に、最初と最後の行、先頭にゼロがあるフィールド、引用符・カンマ・改行を含むフィールドを抜き取り検査してください。
データ形式の選び方
JSONは、APIが返すものやプログラムが読み取るものの既定の選択です。入れ子構造、数値、真偽値、nullを自然に扱え、どの言語でもパースできます。CSVはより小さく、表計算ソフトでそのまま開けますが、入れ子を表現する方法がなく、区切り文字、引用符、文字コードに関する共通規格もありません。変換がうまくいかないのはまさにこの点です。XMLは冗長ですが、属性、混在コンテンツ、スキーマを扱えるため、文書形式や既存の連携では今も主流です。YAMLは設定ファイルにとって最も読みやすい形式ですが、空白に敏感で、型の自動変換が意外な結果を生みます（「no」がfalseになったり、1.10のようなバージョンが1.1になったりします）。見た目が最もよいものではなく、利用する側のツールが好む形式を選んでください。