Как согласовать часовые пояса в CRM и аналитике

Покупатель оформил заказ в 23:59 по местному времени, а в отчёте он оказался на следующем дне. Само по себе это может быть правильно: отчёт построен в другом часовом поясе. Проблема начинается, когда сегмент, эксперимент и отправка используют разные границы суток, но называются одинаково.

Момент времени и календарная дата — разные данные. Один и тот же момент соответствует разному местному времени в разных регионах. UTC — общая временная шкала без сезонного перевода часов; часовой пояс задаёт правила перевода момента в местные дату и время.

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

Храните однозначный момент события

Запись «22 сентября, 23:59» неполна без года и информации о часовом поясе или смещении. RFC 3339 описывает формат временных меток с указанием связи с UTC. Например, 2026-09-22T23:59:00+03:00 и 2026-09-22T20:59:00Z обозначают один момент. [1]

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

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

Выберите часовой пояс каждого расчёта

Для финансового дня может использоваться зона бизнеса, для местного магазина — зона точки, для времени сообщения — подтверждённая зона клиента. Эти правила могут различаться, если различие описано и соответствует задаче.

Не определяйте часовой пояс только по текущему IP, когда нужны устойчивые ограничения отправки. Клиент может путешествовать или пользоваться VPN, при котором видимый сетевой адрес не указывает на фактическое местоположение. В записи зоны полезны источник, время обновления и допустимый запасной вариант.

Различайте сутки и календарный день

Условие «через 24 часа» и условие «завтра в 10 утра» описывают разные расписания. Первое задаёт длительность, второе — местный календарный момент. Разница проявляется даже без сезонного перевода часов.

Для международных проектов учитывайте, что правила часовых поясов меняются. IANA поддерживает базу исторических и текущих правил зон, включая изменения смещений и переходов. Название зоны, например Europe/Berlin, содержит больше смысла, чем навсегда записанное смещение +02:00. [2]

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

Используйте непересекающиеся границы периода

Для соседних интервалов удобно включать начало и исключать конец: от 00:00 выбранного дня включительно до 00:00 следующего дня исключительно. Тогда событие на границе попадёт ровно в один период.

Формулировка «до 23:59:59» может потерять доли секунды. Сначала определите календарные границы в нужной зоне, затем переведите их в однозначные моменты для запроса.

Для окон эксперимента правила одинаковы для всех сравниваемых групп. Если одной группе дают семь полных суток от назначения, а другой — остаток календарной недели, сравнение уже неравноправно.

Условный пример двух отчётов

Магазин работает по московскому времени. Заказ сделан 22 сентября в 01:15 UTC+3. Это 21 сентября в 22:15 UTC. Отчёт по Москве относит покупку к 22 сентября, технический отчёт по UTC — к 21 сентября.

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

Аналогично клиент в другом регионе может попасть в сегмент «покупал сегодня» позже или раньше ожидаемого. Поэтому в описании сегмента нужно указать, чей именно день имеется в виду.

Отдельно храните даты без времени

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

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

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

Проверьте время на граничных случаях

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

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

Готовый результат — короткий стандарт времени: формат обмена, источник часов, зона каждого отчёта, границы окон и правила планировщика. Он устраняет споры о «неправильном дне», которые на самом деле вызваны разными определениями.

Источники

[1] Klyne G., Newman C.. Date and Time on the Internet Timestamps. IETF. RFC 3339. 2002. Раздел 5.6 Internet Date/Time Format. Проверено 22.09.2026.

[2] Internet Assigned Numbers Authority. Time Zone Database. Описание базы часовых поясов IANA и обновления правил. Проверено 22.09.2026.