ZivoLab

概要

このタイムスタンプ変換ツールは、Unix 時間をブラウザ内ですばやく確認したいときに便利です。現在時刻と epoch 値を 1 秒ごとに確認でき、既存のタイムスタンプをローカル時刻や UTC の読みやすい形式に変換したり、指定した日時を Unix 秒やミリ秒へ戻したりできます。API、ログ、データベース、スケジュール確認、デバッグ作業に向いています。

使い方

まずライブパネルで現在時刻と対応する epoch 秒・ミリ秒を確認します。次に「Epoch から日時へ」でタイムスタンプを入力し、単位が秒かミリ秒かを選びます。するとローカル時刻、UTC、ISO 8601、曜日、現在との差がすぐ表示されます。「日時から Epoch へ」ではローカル日時を選ぶだけで Unix 秒とミリ秒が得られます。日時入力は現在の端末タイムゾーンとして解釈される点に注意してください。

主な機能

  • •現在時刻、epoch 秒、epoch ミリ秒を 1 秒ごとに更新
  • •epoch からローカル時刻、UTC、ISO 8601、曜日、相対時間へ変換
  • •ローカル日時を Unix 秒・ミリ秒へ逆変換
  • •API、ログ、JWT の時刻確認、定時実行、データベース確認に便利
  • •すべてブラウザ内で処理され、サーバーへ送信しない

秒とミリ秒を取り違えやすい理由

Unix タイムスタンプには主に秒とミリ秒の 2 つの単位があります。多くの API、JWT claim、バックエンドの payload では秒が使われます。一方で JavaScript Date.now() やブラウザ側のイベントではミリ秒が一般的です。変換結果が極端に未来や過去になる場合、単位の選択ミスが最もよくある原因です。

よくある利用シーン

アプリのログ確認、失効時刻のチェック、定時ジョブの検証、分析イベントの確認、フロントエンドとバックエンドの時計比較などで役立ちます。データベースの値が epoch 秒なのか、epoch ミリ秒なのか、ISO 文字列なのかを見分けたいときにも便利です。

ローカル時刻と UTC を両方見る意味

UTC はチーム、サーバー、ユーザーが別のタイムゾーンにいても共有しやすい基準です。ローカル時刻は、端末やユーザーが実際に見た時刻に近いという利点があります。両方を並べて確認することで、オフセット、夏時間、タイムゾーンの思い込みによるミスを減らせます。

結果が合わないときの確認ポイント

まず秒かミリ秒か、次に元システムが UTC 前提か、ローカル入力を別のタイムゾーンとして読むべきか、最後に端末時計が正しいかを確認してください。多くのズレはこの順番で原因にたどり着けます。

どの入力方法を使うべきか

データの出所に合わせて変換方法を選びます。

入力タイプ向いている場面注意点
epoch 秒JWT claim、多くの API、Unix コマンド出力日付が古すぎるなら、元データが実はミリ秒ではないか確認します
epoch ミリ秒JavaScript Date、ブラウザログ、フロントエンドイベント現代の日付では 13 桁前後になることが多いです
ローカル日時スケジュール確認、手動チェック、DB レビュー入力は現在の端末タイムゾーンで解釈されます

出力フィールドの見方

出力形式ごとに確認しやすい内容が異なります。

出力確認しやすいこと代表的な用途
ローカル時刻この端末でどう見えるかユーザー報告や地域差の確認
UTC / ISO 8601タイムゾーンに依存しない基準サーバー比較、ログ、共同デバッグ
相対時間現在からどれくらい離れているか有効期限、鮮度、スケジュール確認

よくある質問

Unix タイムスタンプは秒とミリ秒のどちらを使うべきですか？

元システムが期待する単位に合わせてください。API や JWT claim は秒が多く、JavaScript Date 値はミリ秒が一般的です。

変換した日付が何百年もずれて見えるのはなぜですか？

多くの場合は単位の選択ミスです。秒をミリ秒として読むと古すぎる日時になり、ミリ秒を秒として読むと未来すぎる日時になります。

日時から epoch への変換は UTC を使いますか？

いいえ。ローカル日時入力は現在の端末タイムゾーンとして解釈されたうえで Unix 時間に変換されます。

UTC とローカル時刻を同時に見る理由は何ですか？

UTC はシステム間で共有しやすい基準で、ローカル時刻はユーザーや端末が実際に見た時刻を理解するのに役立つからです。

入力した値はサーバーへ送信されますか？

いいえ。変換はブラウザ内で完結するため、値は端末内に留まります。