🛠️ Отчёт за 17 июня готов, запрос выполнился без ошибок, цифры выглядят правдоподобно.
Но операции около полуночи попали не в тот отчётный день.
Ошибка недели — фильтровать данные по дате, не проверив тип поля и часовой пояс.
Например, 18 июня в 00:30 по Москве — это 17 июня 21:30 UTC. Если отчёт строится по UTC или значение приводится к date до перевода в нужную зону, событие окажется в отчёте за 17 июня.
Что проверить: Тип и смысл поля date, timestamp without time zone и timestamptz — не одно и то же.
timestamp without time zone не содержит данных о зоне и не означает UTC автоматически. timestamptz представляет конкретный момент времени, но не хранит исходное название зоны: отображение зависит от TimeZone текущей сессии.
Отчётная зона По какой зоне определяется день: UTC, времени пользователя, филиала или бизнеса? Это правило должно одинаково пониматься приложением, базой и BI-системой.
Границы периода Для временных значений используйте полуоткрытый интервал: начало включительно, конец исключительно.
Например, для поля event_time типа timestamptz и отчётного дня по Москве:
WHERE event_time >= TIMESTAMP '2026-06-17 00:00:00' AT TIME ZONE 'Europe/Moscow' AND event_time < TIMESTAMP '2026-06-18 00:00:00' AT TIME ZONE 'Europe/Moscow'
Так соседние периоды не пересекаются, а события с дробной частью секунды не выпадают.
Порядок преобразований Если хранится timestamptz, сначала переведите момент в отчётную зону и только затем определяйте локальную дату. Простое приведение к date зависит от часового пояса сессии.
Изменение смещения Для регионов с переходами DST фиксированное прибавление часов ненадёжно. Используйте именованную временную зону с её правилами.
Типичная ошибка — задавать конец дня как 23:59:59 или приводить timestamp к дате без учёта типа поля и отчётной зоны.
Практический вывод: отчётный период — это не только две даты. Важны тип временного поля, часовой пояс и однозначные границы интервала.
Перед публикацией отчёта проверьте, в какой зоне определяется день и как рассчитываются начало и конец периода.
🔹🔹🔹🔹