【要約】『今日の既読件数』が9時間ズレていた日 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、個人開発アプリ「AgentPick」の既読件数が実際の数値と食い違う問題に直面した。原因は、タイムゾーン情報を持たない「naive datetime」の基準が、生成場所によってバラバラであったことにある。具体的には以下の課題があった。
- ・アプリのプロセス時計とDBサーバーの時計の不一致。
- ・外部API（Qiita, GitHub, RSS）由来のタイムゾーン情報の混在。
- ・DBドライバが保存時にタイムゾーン情報を黙って破棄する仕様。
- ・環境がたまたま一致しているために、バグが潜在化していた点。
// Approach
開発者は、データの生成元と基準となる時計を明示的に一致させるアプローチを採用した。基準を揃えることで、環境の変化に左右されないロジックへと作り替えた。
- ・集計境界の生成を、アプリの時計ではなくDBの時刻（
func.now()相当）に統一。 - ・外部データの保存前に、必ずUTCへ変換してからnaive datetime化する正規化処理を導入。
- ・環境変数でタイムゾーンを意図的に変更し、不整合を検知するテストコードを実装。
// Result
開発者は、インフラ環境の変化に耐えうる、原理的に正しい集計ロジックを実現した。
- ・アプリがどのタイムゾーンで動作しても、DBの時計を基準とした正確な集計が可能。
- ・異なるソースのデータも、DB内でUTC基準のnaive datetimeとして一貫性を保持。
- ・「たまたま動く」状態を排除し、コンテナ化等の環境変更に対する堅牢性を獲得。
Senior Engineer Insight
> naive datetimeの扱いは、分散システムにおける「見えない爆弾」である。コンテナ化やクラウド移行で環境が変わった瞬間に、このバグは顕在化する。単に型を合わせるのではなく、「どの基準の時刻か」というコンテキストをコードレベルで保証する設計が不可欠だ。テストにおいても、正常系だけでなく、意図的に環境を歪めた異常系（時差の大きい環境）での検証が、真の堅牢性を担保する。現場では、DBとアプリの時刻基準を一致させる、あるいは常にUTCで統一する運用を徹底すべきである。