Unixタイムスタンプとは
Unixタイムスタンプ（Unix time、POSIX time、Epoch timeとも呼ばれます）とは、協定世界時（UTC）1970年1月1日0時0分0秒からの経過秒数で時刻を表現する方式です。この起点となる日時を「Unixエポック」と呼びます。たとえばタイムスタンプの値が「0」であれば1970年1月1日0時0分0秒（UTC）を意味し、「1700000000」であれば2023年11月14日22時13分20秒（UTC）を意味します。タイムゾーンに依存しないシンプルな数値表現であるため、世界中のシステムで統一的に時刻を扱える利点があります。
なぜ1970年1月1日が起点なのか
Unixエポックが1970年1月1日に設定された理由は、Unixオペレーティングシステムの歴史にあります。Unixが開発されたのは1960年代後半から1970年代初頭にかけてであり、当時のシステムでは32ビット整数で時刻を管理していました。1970年1月1日はUnixの初期バージョンが実用化された時期に近く、切りのよい日付として選ばれたとされています。当初は1/60秒単位で記録されていましたが、後に秒単位に変更されました。この設計判断は半世紀以上経った今でもコンピュータ業界全体の標準として使われ続けています。
2038年問題（Y2K38問題）
32ビットの符号付き整数でUnixタイムスタンプを格納している場合、表現できる最大値は2,147,483,647（2の31乗マイナス1）です。この値に到達するのが2038年1月19日3時14分7秒（UTC）であり、その直後にオーバーフローが発生して時刻が1901年12月13日に巻き戻ってしまう可能性があります。これが「2038年問題」または「Y2K38問題」と呼ばれるものです。2000年問題（Y2K）に似た性質を持つこの問題に対処するため、現代の多くのシステムでは64ビット整数への移行が進められています。64ビットであれば約2920億年先まで表現可能なため、実質的に問題は解消されます。ただし、組み込みシステムやレガシーソフトウェアでは依然として32ビットが使われている場合があり、注意が必要です。
タイムスタンプの主な用途
Web API・データベース
REST APIやGraphQL APIのレスポンスでは、作成日時や更新日時をUnixタイムスタンプで返すことが一般的です。データベースにおいても、MySQLのINT型カラムやMongoDBの内部表現などでタイムスタンプが広く使われています。数値として格納するためインデックスの効率が良く、タイムゾーンに依存しないため異なるリージョン間でのデータ同期にも適しています。
ログ解析・監視
サーバーログやアプリケーションログでは、各エントリにタイムスタンプが付与されます。障害対応やパフォーマンス分析の際に、タイムスタンプを人間が読める日時に変換して時系列を把握することが重要です。特にマイクロサービス環境では、複数のサービスから出力されるログのタイムスタンプを照合して原因を特定する場面が頻繁にあります。
タイムゾーンの考慮
Unixタイムスタンプ自体はUTCベースの絶対的な値ですが、日時に変換する際にはタイムゾーンを考慮する必要があります。日本標準時（JST）はUTC+9ですので、同じタイムスタンプでもJSTで表示すると9時間進んだ時刻になります。国際的なサービスを開発する場合、サーバー側ではUTCでタイムスタンプを保存し、クライアント側でユーザーのローカルタイムゾーンに変換して表示するのがベストプラクティスです。このツールでは、ブラウザのローカルタイムゾーンとUTCの両方を表示するため、変換結果を正確に確認できます。