Unix タイムスタンプを理解する
Unix タイムスタンプは単なる数値なので簡単そうに見えますが、ウェブの作業ではほぼあらゆる場所に登場します。API、ログ、エクスポート、キューのメッセージ、イベント記録などはすべてこれに依存しています。フォーマットは 1970 年 1 月 1 日 UTC からの秒数(またはミリ秒)を数える 1 つの整数だけです。
利点は一貫性です。タイムスタンプはコンパクトで、保存レベルではタイムゾーンに依存せず、ソフトウェアにとって比較、並べ替え、送信が容易です。難点は、それ自体では読めないことです。1710153600 のような値は、日付に変換するまで何も教えてくれません。
そのためタイムスタンプ用のツールは、経験豊富な開発者にとっても有用であり続けます。次のような実用的な質問にすばやく答える必要がよくあります。これは秒かミリ秒か? UTC とローカルで何日を表しているか? テストリクエスト用に特定の日付に対応するタイムスタンプは何か?
どんなときに役立つか
created_atやexpires_atのような数値の時間フィールドを返す API レスポンスを確認する。- イベント時刻が生の Unix 値として保存されているログを確認する。
- バックエンドサービスとブラウザ間のタイムゾーンに関する問題をデバッグする。
- リクエストやペイロードをテストする前に、人間に分かる日付を Unix 時間に変換する。
実用的な例
API が JSON ペイロードで 1710153600 を送ってきたと想像してください。一見しただけでは何も分かりませんが、変換すると特定の UTC 日付と自分のタイムゾーンでのローカル日付に対応していることが分かります。これで値が妥当かどうか、あるいは数時間・数日・さらには 1000 倍規模でずれていないかがすぐ判別できます。
ここでミリ秒も効いてきます。1710153600000 のような値は同じ瞬間を表しますが、秒ではなくミリ秒です。両者を取り違えると、日付はまったくのデタラメになります。
よくあるユースケース
- ペイロード内のタイムスタンプフィールドが秒なのかミリ秒なのかを確認する。
- UTC でのイベント時刻と、ユーザーがローカルで見るものを比較する。
- テストやデモ用に、サンプルの有効期限値を作成する。
- バックエンドとフロントエンドのコードが同じ方法で変換しているかを確認する。
- 別途コンソールやスクリプトを開かずに、古いエクスポートデータを読む。
ブラウザ上のコンバーターを使う
ブラウザ上のツールを使えば、数秒で実行できます。
よくある質問
なぜタイムスタンプは UTC を使うのですか?
UTC はソフトウェアに 1 つの安定した基準点を与えます。読みやすいローカル表示はタイムゾーンによって変わりますが、保存されたタイムスタンプは変わりません。
なぜ 10 桁のタイムスタンプと 13 桁のタイムスタンプがあるのですか?
10 桁は通常「秒」、13 桁は通常「ミリ秒」を意味します。
UTC とローカル時刻の両方が必要ですか?
デバッグ中なら、たいていは「はい」です。UTC はシステム間の比較に役立ち、ローカル時刻は人が実際に見たものを確認するのに役立ちます。