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

TIMESTAMP WITH TIME ZONE предназначен для значения, однозначно связанного с моментом времени, тогда как TIMESTAMP WITHOUT TIME ZONE хранит только дату и время без информации о часовом поясе и смещении. Для событий, которые должны корректно сопоставляться во времени между часовыми поясами, обычно нужен первый вариант; для локального расписания — второй.

Исторический контекст

Разделение появилось из-за двух разных задач: фиксировать абсолютный момент, например время платежа, или хранить локальное показание часов, например время открытия магазина. Смешение этих смыслов приводит к ошибкам при переносе данных между регионами и переходах на летнее или зимнее время.

Постановка проблемы

Если сохранить момент события как timestamp без часового пояса, значение вроде «10:00» не сообщает, к какому региону оно относится. Система не сможет надежно определить, раньше или позже произошло событие в другой временной зоне.

Обратная ошибка тоже возможна: расписание «каждый день в 09:00 по местному времени» нельзя бездумно трактовать как один фиксированный момент UTC. После изменения часового пояса или перехода на летнее время локальное время может соответствовать другому моменту.

Подробное решение

TIMESTAMP WITHOUT TIME ZONE хранит календарные дату и время как отдельное локальное значение. Часовой пояс не является частью значения, поэтому при чтении невозможно восстановить исходную временную зону, если она не хранится в другом столбце.

TIMESTAMP WITH TIME ZONE выражает значение с учетом временной зоны или смещения. Однако конкретное внутреннее хранение и правила отображения зависят от СУБД: некоторые системы нормализуют значение к UTC и показывают его в часовом поясе текущей сессии, а не сохраняют исходное название зоны.

Поэтому для аудита часто хранят момент события в типе с часовым поясом, а при необходимости отдельно сохраняют исходную зону пользователя, например Europe/Moscow. Это позволяет различать абсолютный момент и исходный контекст его отображения.

Следует учитывать, что SQL-стандарт и конкретные СУБД могут различаться в деталях поддержки, преобразований и отображения этих типов. Нельзя переносить поведение одной СУБД на другую без проверки документации.

Минимальная иллюстрация различия:

CREATE TABLE events (
    event_id INTEGER PRIMARY KEY,
    occurred_at TIMESTAMP WITH TIME ZONE,
    local_time TIMESTAMP WITHOUT TIME ZONE
);

В occurred_at следует помещать момент, который нужно сравнивать с другими событиями. В local_time — локальное время, если оно само является предметным значением и его зона задается отдельно или заранее известна из контекста.

Ситуация из практики

Сервис доставки работает в нескольких странах и записывает время принятия заказа. Вариант с TIMESTAMP WITHOUT TIME ZONE прост, но приводит к неоднозначности: одинаковые значения из разных регионов невозможно правильно упорядочить без дополнительного смещения.

Вариант с TIMESTAMP WITH TIME ZONE надежно сохраняет момент и упрощает сортировку, но может отображать время иначе, чем видел пользователь. Отдельное хранение исходной зоны повышает точность интерфейса, но усложняет модель данных и валидацию названий зон.

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

Что кандидаты часто упускают

1. Достаточно ли хранить смещение, например +03:00, вместо названия часовой зоны?

Нет, это разные сведения. Смещение описывает положение относительно UTC в конкретный момент, но не содержит правил региона. Название зоны вроде Europe/Moscow позволяет применять исторические и будущие правила переходов, если они поддерживаются используемыми библиотеками и данными о зонах.

2. Всегда ли значение с часовым поясом при чтении отображается в той зоне, которая была указана при записи?

Нет, это не гарантируется общей моделью SQL. СУБД может хранить абсолютный момент, а отображать его с учетом часового пояса текущей сессии; исходное представление зоны при этом не восстанавливается. Если исходная зона важна для бизнеса, ее нужно хранить отдельно.

3. Какой тип выбрать для события «встреча начинается в 09:00 по местному времени»?

Одного timestamp недостаточно для полноценного расписания. Нужно хранить локальное время и часовую зону, а для конкретного экземпляра встречи дополнительно учитывать дату и правила перехода зоны. Если сохранить только абсолютный момент, повторяющееся расписание может начать показываться не в 09:00 после изменения смещения.