DynamoDB で日付（日時）を扱うとき、「ISO 8601（ATOM形式）で保存するべき」という説明をよく見かけます。
ただ、少し整理してみると、DynamoDB が本質的に求めているものは“日時”そのものではなさそうです。
DynamoDB における本質
- ATOM（ISO 8601）文字列である必要はない
- ただし「文字列比較＝日時の前後関係」になる形式である必要がある
- DynamoDB が求めているのは “日時” ではなく “ソート可能なキー”
ここが設計上の重要ポイントだと理解しました。
なぜ「文字列比較」が重要なのか
DynamoDB の Sort Key（および GSI の Sort Key）は、型によって比較方法が異なります。
- 数値なら数値比較
- 文字列なら辞書順比較（lexicographical order）
例えば次のようなクエリを書く場合：
created_at BETWEEN :from AND :to
これが正しく動くには、
"from" <= created_at <= "to"
が文字列としても成立している必要があります。
つまり、
日時の前後関係 ＝ 文字列の大小関係
になっていなければなりません。
見た目が日時であっても、この条件を満たしていない形式では Range Query が意図どおり動かない可能性があります。
文字列として安全な日時フォーマットの条件
文字列ソートで正しく比較させるためには、いくつか条件があります。
必須条件
- 年 → 月 → 日 → 時 → 分 → 秒 の順で並ぶ
- 各桁がゼロ埋めされた固定長
- タイムゾーンが揃っている（または UTC 固定）
この3点を満たしていれば、ISO 8601 でなくても問題は起きにくいと考えられます。
具体例
ATOM / ISO 8601（王道）
2025-09-27T14:23:45Z
スペース区切り（MySQL互換形式）
2025-09-27 14:23:45
どちらも
- 年 → 月 → 日 → 時 → 分 → 秒 の順
- ゼロ埋め固定長
- 同一タイムゾーン
という条件を満たしているため、文字列比較でも正しく前後関係が保たれます。
ATOM（ISO 8601）が選ばれやすい理由
技術的に必須というより、設計上の安全性が高いことが理由のようです。
- RFCで標準化されている
- タイムゾーン情報を含められる
- 多言語・多サービスで共通フォーマット
- 将来、別システムにデータを渡しても壊れにくい
つまり、
技術的必須ではないが、設計的に安全
という位置づけで採用されることが多いと理解しています。
まとめ
DynamoDB で日時を扱う場合、重要なのは「ISO 8601かどうか」ではなく、
その値がソートキーとして正しく比較できるか
という点にあります。
DynamoDB が扱っているのは「日時」という概念ではなく、あくまで「キーの比較」です。
今後設計する際には、
- 文字列で保存するか
- 数値（UNIXタイム）で保存するか
- GSI をどう設計するか
といった判断を、「日時形式」ではなく「比較可能性」を基準に考えていこうと思います。