おつかれさまです、yokochanです！
データ分析業務において、時系列データを扱う際、「UTC（協定世界時）のままで日集計してしまう」ことによって思わぬ落とし穴にはまることがあります。特に日本国内のサービスであれば、必ずこの落とし穴を回避するための工夫が必要です。本記事では、その理由と具体例を交えて解説します。
なぜUTCでの日集計が問題なのか？
多くのシステムでは、時刻情報がUTCで記録されます。これはグローバルな標準時であり、各国のタイムゾーンに左右されず一貫性が保たれるというメリットがあります。
しかし、日単位での集計を行う場合には注意が必要です。たとえば、日本標準時（JST）はUTCより9時間進んでいます。つまり、UTCでの「2024-01-01」は、JSTでは「2024-01-01の午前9時」から始まり、「2024-01-02の午前9時」で終わることになります。
このズレを無視してUTCベースで日集計してしまうと、日本時間で考える「1日」の感覚とは異なる結果になってしまいます。
具体例：ECサイトの売上データを集計した場合
あるECサイトの売上データが、すべてUTCで記録されているとします。たとえば以下のようなデータがあるとします。
| 購入日時 (UTC) | 金額 |
|---|---|
| 2024-06-12 23:30:00 | ¥3,000 |
| 2024-06-13 01:00:00 | ¥2,000 |
| 2024-06-13 14:00:00 | ¥5,000 |
このデータをUTCのまま日付（DATE）でグルーピングして集計すると、以下のようになります：
| 日付 (UTCベース) | 合計金額 |
|---|---|
| 2024-06-12 | ¥3,000 |
| 2024-06-13 | ¥7,000 |
一見正しそうに見えますが、これを日本時間に変換してから日付で見てみましょう：
- 2024-06-12 23:30:00 UTC → 2024-06-13 08:30:00 JST
- 2024-06-13 01:00:00 UTC → 2024-06-13 10:00:00 JST
- 2024-06-13 14:00:00 UTC → 2024-06-13 23:00:00 JST
すべて2024年6月13日（JST）に発生した売上です。したがって、日本時間で考えると、正しい日集計結果は：
| 日付 (JSTベース) | 合計金額 |
|---|---|
| 2024-06-13 | ¥10,000 |
UTCのままで集計してしまうと、2024-06-12の売上として誤って扱ってしまうという問題が発生していることがわかります。
解決策：適切なタイムゾーン変換を行う
この問題を回避するためには、日付でのグルーピングを行う前にタイムゾーン変換を行う必要があります。
以下は簡易的な例です。
- BigQueryの場合:
DATETIME(TIMESTAMP, "Asia/Tokyo")を使って変換 - Python (pandas) の場合:
df['datetime'].dt.tz_convert('Asia/Tokyo') - SQLの場合:
AT TIME ZONE 'Asia/Tokyo'
このようにして、ローカル時間（JST）に変換したうえで日付抽出・グルーピングを行うことで、意図した通りの「1日」単位での集計が可能になります。
まとめ
- 多くのシステムはUTCで時刻を記録している。
- そのまま日付でグルーピングすると、日本時間での「1日」とズレた結果になる。
- 特に業務報告や売上分析など、日単位の集計が重要なシーンで深刻な誤解を招く。
- 集計前にタイムゾーン変換を行うことで、正確な結果を得られる。
最後に
時系列データの分析において、「日付」は最も身近でありながら誤りが起こりやすいポイントです。UTCとローカル時間の差を正しく意識し、常に集計の前に「これは日本時間で合っていますか？」と確認する癖をつけましょう。
