Почему при объединении данных из разных систем сумма заказов «не бьётся», если в одной системе время хранится в UTC, а в другой — в локальном часовом поясе?

Короткий ответ

Если одна таблица хранит время в UTC, а другая — в локальном часовом поясе, группировка «по дню» без приведения к единому часовому поясу сдвигает часть событий в соседние календарные сутки, из-за чего суммы по дням в двух системах расходятся даже на одинаковых исходных данных.

Как это работает подробнее

календарный день (DATE) зависит от часового пояса — событие, случившееся в 23:30 UTC, в часовом поясе UTC+3 уже относится к следующему дню. Если группировать по дате без явного приведения обеих таблиц к одному часовому поясу, границы «дня» в двух источниках будут отличаться.

Пример кода

question-33.sqlКопировать

SELECT DATE(event_time AT TIME ZONE 'UTC' AT TIME ZONE 'Europe/Moscow') AS local_day,
       COUNT(*) AS events_cnt
FROM events
GROUP BY 1;

Что использовать на практике

• перед объединением данных из разных систем важно явно узнать (не предполагать), в каком часовом поясе хранится каждая временная метка, и привести все значения к единому поясу (например, через AT TIME ZONE в PostgreSQL) прежде, чем группировать по дате. Проверка: для события на границе суток (например, 2024-05-01 23:50:00 UTC) результат local_day должен быть 2024-05-02 при пересчёте в московское время — сверить вручную на нескольких примерах.

Подводные камни

• считают, что раз в базе указан timestamp, то часовой пояс «не важен» и сравнение корректно само по себе; расследуют расхождение сумм как ошибку логики запроса, хотя на самом деле проблема — в несогласованных исходных данных.