Почему дата покупки в отчёте сдвинулась на день

Покупатель оплатил заказ ночью, а в отчёте магазина операция оказалась во вчерашнем дне. На первый взгляд данные испорчены. Но возможна другая причина: оплата записана в одном часовом поясе, а суточный отчёт построен в другом. Сама покупка не переместилась во времени — изменилось правило, по которому ей назначили календарную дату.

Такую ситуацию полезно отличать от задержки загрузки. Часовые пояса отвечают на вопрос «к какому дню относится событие», а своевременность поступления данных — «когда мы о нём узнали». Обе проблемы могут встретиться одновременно, поэтому исправление только расписания загрузки не обязательно поможет.

Момент события можно представить как одну точку на общей временной шкале. Календарная дата зависит от места и принятого часового пояса. Например, условная покупка произошла 22 сентября в 00:30 по московскому времени. В UTC, международной временной основе, это 21 сентября в 21:30: московское время в этом примере опережает UTC на три часа.

Если отчёт берёт день непосредственно из записи в UTC, покупка попадёт в 21 сентября. Если сначала переводит момент в московское время, то в 22 сентября. Арифметически оба результата объяснимы; правильность для бизнеса зависит от того, какой день договорились считать отчётным.

Записи «00:30» недостаточно: без даты и контекста часового пояса непонятно, какой момент имеется в виду. Для событий из разных регионов обычно важно сохранить однозначное время, а при необходимости — отдельно исходную зону. Дата рождения или дата календарного праздника имеют другой смысл: их не следует автоматически превращать в момент покупки.

Документация PostgreSQL различает данные о времени с учётом и без учёта часового пояса. В частности, хранение момента с учётом зоны не означает сохранение исходного названия этой зоны. Поэтому требования к исходным сведениям нужно определить до обмена данными.

Условная сеть магазинов может считать продажи каждого филиала по его местному дню, а общий финансовый отчёт — по единой зоне головного офиса. Тогда дневные срезы нельзя сравнивать без уточнения правил. Несовпадение не всегда означает потерянные операции: границы отчётов могут охватывать разные интервалы.

Опишите начало и конец периода так, чтобы событие ровно на границе не учитывалось дважды. Например, начало новых суток относится к новому дню, а не одновременно к двум соседним отчётам. Для регионов с сезонным переводом часов также нельзя без проверки считать любые местные сутки равными двадцати четырём часам.

Предположим, источник правильно сохранил момент оплаты. Затем выгрузка отбросила информацию о зоне, а таблица для аналитики приняла оставшееся время за местное. Даже аккуратный график в конце цепочки покажет неверные даты. Проблема появилась раньше, чем пользователь открыл отчёт.

Проверьте последовательно источник, перенос и преобразования перед подсчётом дневных итогов. Роль этих этапов объясняет материал про ETL и ELT. Правила преобразования дат зависят от используемой системы; для PostgreSQL они описаны в документации о работе со временем.

Уточните, какое событие считают: создание заказа, оплату или отгрузку. Затем выясните часовой пояс источника, зону отчёта, границы периода и время последнего обновления. Эти вопросы помогают отделить смысловую разницу от технической ошибки.

Для проверки выберите несколько операций около полуночи и проследите их путь до итоговой таблицы. Отдельно проверьте поздно пришедшие события: день покупки может быть вчерашним, хотя запись поступила сегодня. Здесь пригодится объяснение свежести данных. Зафиксируйте согласованное правило рядом с отчётом, чтобы следующий пользователь не выяснял его заново по случайному примеру.

Продолжить обучение можно по программе Data Engineer для начинающих. Сопоставьте её содержание со своей задачей и текущей подготовкой.

• PostgreSQL: типы даты и времени
• PostgreSQL: работа с датой и временем