Почему важно учитывать Timezone в SQL запросах

Покажу на наглядном и реальном примере. У нас есть дата и время в UNIX-формате, которое выглядит изначально как целое число: 1776373200

А теперь представляем, я подготовил данные для дашборда, написал SQL-запрос и пошел создавать отчет.

Запрос один и тот же, но стоит его запустить в разных местах и можно получить разные даты. Мой запрос

SELECT to_timestamp(1776373200) AS dt, (to_timestamp(1776373200) AT TIME ZONE 'UTC') AS dt_utc, (to_timestamp(1776373200) AT TIME ZONE 'Europe/Moscow') AS dt_msk 1-й скрин показывает результат когда пишу запрос в DBeaver. 2-й скрин когда тот же самый запрос запускаю в Datalens под созданием датасета.

В поле dt разные даты!

Почему так получается? Это не ошибка, а разница часовых поясов, который в случае запуска в DBeaver учитывает мой текущий часовой пояс, а в случае запуска в Datalens дата и время отображаются в UTC. Если оставить запрос как есть в поле dt мы получим расхождение и неправильные метрики в отчете и в базе данных просто потому, что будем как-будто работать в разных часовых поясах. Поэтому важно приводить все временные поля к одному единому часовому поясу, а в запросах лучше указывать его в явном виде, чтобы он не зависел от системных настроек сервера. Ну и не забываем что поля с датами могут сравниваться между собой и также важно чтобы сравниваемые даты были в одном часовом поясе

Ставьте реакции, если теперь будете думать про таймзоны 😉

Почему важно учитывать Timezone в SQL запросах
Покажу на наглядном и реальном примере | Сетка — социальная сеть от hh.ru Почему важно учитывать Timezone в SQL запросах
Покажу на наглядном и реальном примере | Сетка — социальная сеть от hh.ru