Unixタイムスタンプは機械にとっては完璧ですが、人間にとっては役に立ちません。ログ集約ツール、データベースレコード、APIレスポンスのすべてが、1970年1月1日からの秒数を数えた生の整数として時刻を保存しているようで、すべての開発者はある時点で1725580800が最近なのか大昔なのかを目分量で判断しようとしたことがあるはずです。
よくある回避策は、Google検索で「1725580800 to date」と調べることです——動作はしますが、本来2秒で済むはずの作業にブラウザとの往復を加えることになります。あるいは、言語のコンソールでワンライナーを書きます。ブラウザのJSコンソールでnew Date(1725580800000)とし、ミリ秒のために1000を掛けることを思い出し、そもそも秒とミリ秒を混同していないことを願います。
秒とミリ秒——定番の落とし穴
Unix時間は通常は秒単位ですが、JavaScriptのDateオブジェクトはミリ秒を期待しており、一部のAPI(特にJavaScriptベースのもの)はデフォルトでミリ秒のタイムスタンプを返します。これらを混同すると、はるか未来の日付になるか、1970年のエポック付近に張り付いたままの日付になります——「この日付がおかしい」問題をデバッグする際に、すべての開発者が少なくとも一度は犯したことのあるミスです。
タイムゾーンがさらに別の層を加えます。タイムスタンプは特定の瞬間に変換されますが、それをローカル時間、UTC、あるいはサーバーのタイムゾーンで表示するかによって、同じ値がまったく異なる3つの時刻のように見えることがあり、エラーとデプロイを関連付けようとしているときには大きな問題になります。
両方向を即座に変換
Bellowsには、Unixタイムスタンプを読みやすい日付と時刻に変換し、日付をタイムスタンプに逆変換するタイムスタンプコンバーターが含まれています——どちらの方向も計算不要です。秒とミリ秒のあいまいさも処理してくれるので、推測する必要はありません。
ログとデータベースのデバッグ
ログ集約ツール、データベースの行、APIペイロードは、読みやすい文字列よりも生の数値として時刻を保存することがはるかに多いです。インシデントを調査している最中に一握りのタイムスタンプを変換することは、本格的なデバッグセッションで何十回も発生する小さな作業です。
スケジューリングと有効期限のロジック
キャッシュの有効期限、トークンの有効期限、スケジュールされたジョブのタイムスタンプは、内部的にはすべてUnix時間です。特定の有効期限の値が実際の時刻でどれに対応するかを素早く確認することで、TTLロジックが意図した通りに動作しているかを検証できます。