3秒でわかる
出来事が起きた日時を機械が扱える形で表した値。ログの追跡やレコードの作成日時の記録に使い、地域差を避けるため UTC で持つのが定石です。
もう少し詳しく
どういうものか
タイムスタンプは、ある出来事が起きた瞬間を機械が比較できる形で表した値です。代表的なのは Unix 時間で、1970 年 1 月 1 日 00 時 00 分 00 秒 UTC からの経過秒数を整数で持ちます。もう 1 つは ISO 8601 形式の文字列で、年月日と時刻を並べた表記なので人間にも読めます。データベースでは TIMESTAMP 型や DATETIME 型として列に持たせます。
なぜ必要か
「8 月 14 日の朝」という表現は、書いた人の場所によって指す瞬間が変わります。サーバーが東京、利用者がロンドン、ログ基盤が UTC という構成では、同じ事象の記録が 9 時間ずれて並びます。基準点からの経過秒という 1 本の数直線に載せてしまえば、比較も差分計算も文字列比較も曖昧さなく行えます。
具体例
from datetime import datetime, timezone
now = datetime.now(timezone.utc)
print(now.isoformat()) # 2026-08-14T09:30:00+00:00
print(int(now.timestamp())) # 1786...
# 保存済みの秒数から日時へ戻す
saved = 1786000000
print(datetime.fromtimestamp(saved, timezone.utc))CREATE TABLE orders (
id BIGINT PRIMARY KEY,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);つまずきやすいところ
Date.now() はミリ秒、多くの言語やログ基盤は秒DATETIME はタイムゾーン変換をせず、TIMESTAMP は変換するなど、DB 製品ごとの差がある似た用語との違い
エポック秒は数値なので計算が速く保存も軽い一方、目で見て日時が分かりません。ISO 8601 文字列は読めますが比較コストが上がります。ログには文字列、集計対象の列には数値または日時型という使い分けが多く採られます。
覚え方
扱う粒度を最初に決めておくことも重要です。秒までで足りるのか、ミリ秒が必要なのか、同一秒内の順序を保証したいのかによって設計が変わります。同一秒に複数件が入りうるログを時刻だけで並べ替えると順序が不定になるため、連番や ULID のような単調増加する識別子を併せて持たせる設計がよく採られます。
「基準の日からの通し番号」です。番号で持ち、見せる直前に日付へ翻訳します。