Напоминания клиентам и сотрудникам: часовые пояса и тихие часы

Чтобы напоминание пришло вовремя в любом часовом поясе, я храню время события в UTC, пояс человека отдельным полем в формате IANA, а срабатывание планирую от абсолютного момента. Тогда перевод часов, переезд и разница между городами не ломают расписание. Ниже разбираю, как это устроено для бота и мини-приложения, где напоминания уходят клиентам и сотрудникам.

Что хранить: время в UTC и пояс пользователя

Самая частая ошибка выглядит так: в базе лежит строка «25.11 18:00», и непонятно, чьи это 18:00. Сервер стоит в одном городе, клиент живёт в другом, а сотрудник в командировке в третьем. Поэтому я записываю два значения.

• Момент события в UTC. Это точка на общей шкале времени, она одинакова для всех.
• Пояс человека как имя из базы IANA. Например Europe/Moscow или Asia/Dubai. По описанию на странице IANA база содержит код и данные об истории местного времени для многих представительных мест мира и обновляется периодически, когда власти меняют границы поясов, смещения от UTC или правила перехода на летнее время.

Последний пункт и есть причина не хранить голое смещение. Запись «+03:00» теряет знание о том, какие правила действуют в этом месте. Имя пояса позволяет библиотеке или браузеру посчитать верное смещение на любую дату.

Имя пояса понимает и браузер. По документации MDN параметр timeZone в Intl.DateTimeFormat принимает имена из базы IANA, включая UTC, и идентификаторы-смещения, а по умолчанию берёт пояс среды выполнения. Поэтому в мини-приложении я показываю время стандартным Intl и не пишу собственных пересчётов.

Откуда взять пояс человека

У мини-приложения и сайта пояс можно спросить у браузера. На странице resolvedOptions MDN сказано, что свойство timeZone возвращает имя пояса из базы IANA, по умолчанию пояс среды выполнения. Я беру это значение при первом входе и записываю в профиль.

У бота в чате браузера нет. Там я спрашиваю один раз кнопками: несколько самых частых поясов и пункт «другой». Угадывать пояс по номеру телефона я не стал бы: номер может быть куплен в одном городе, а человек живёт в другом. Важно, чтобы пояс можно было поправить в профиле в любой момент, об этом ниже.

Напоминание за сутки и за 2 часа

Для записи на приём и встреч мне хватает двух напоминаний: за сутки и за 2 часа. Первое даёт время перестроить день или перенести, второе возвращает в голову то, что случится скоро. Больше двух начинает раздражать, меньше теряет смысл. Это моя рабочая схема, под ваш бизнес её можно сдвинуть.

Расчёт простой. Берётся момент события в UTC, вычитаются 24 часа и 2 часа, получаются два момента отправки. В очередь кладутся именно они. Часовой пояс нужен только в двух местах: чтобы показать человеку время в тексте и чтобы проверить тихие часы.

Пример из практики: в проекте для частного врача бот присылает пациенту напоминания за сутки и за два часа, а врачу утром в 8:00 приходит сводка на день. Номер кабинета меняется, поэтому бот спрашивает его у врача утром и подставляет в напоминания. Напоминание должно содержать то, что актуально именно сейчас.

Про сами напоминания как способ сократить неявки я писал отдельно: неявки на запись, предоплата и напоминания и подтверждение визита в клинике.

Перевод часов и ловушки местного времени

Там, где часы переводят, в день перехода местное время ведёт себя неудобно: одного часа на циферблате может не быть, а другой может случиться дважды. Если хранить «18:00 по местному» без пояса и даты, при пересчёте легко получить сдвиг на час. Если хранить момент в UTC и считать отправку от него, этой проблемы нет: между отметкой «за 24 часа» и самим событием проходит ровно 24 часа на абсолютной шкале.

Ловушка остаётся в повторяющихся событиях вроде «каждый вторник в 10:00». Здесь я храню правило повтора и пояс, а конкретные моменты UTC вычисляю заранее на ближайший период. Так после смены правил в базе IANA ближайшие экземпляры пересчитываются верно, и старые записи переписывать не нужно.

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

Тихие часы: ночью не пишем

Напоминание в три часа ночи по местному времени человека хуже, чем отсутствие напоминания. Поэтому у каждого получателя есть окно, в котором бот молчит. В приложении руководителя команды это период с 22 до 8 по местному времени человека, а утренний план приходит в 9:00.

Что делать с сообщением, которое попало в тихие часы:

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

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

Повторы и архив

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

Выполненное и прошедшее убираю в архив и не удаляю. В приложении руководителя это делается свайпом, и вкладки «Мне поручили» и «Я поставил» остаются чистыми. Архив пригождается в спорах вроде «мне не приходило»: по записи видно, что было отправлено и когда.

Что делать, если пользователь переехал

Человек улетел в другую страну или переехал в другой город, а бот продолжает считать по старому поясу. Я решаю это тремя правилами.

• Пояс в профиле меняется в пару нажатий. В приложении руководителя он подхватывается из браузера и правится в профиле.
• При смене пояса пересчитываются все будущие напоминания. Абсолютный момент события остаётся прежним, меняется показ времени и положение тихих часов.
• В поручениях срок хранит пояс автора и показывается по часам того, кто смотрит. Руководитель поставил срок до 18:00 по своему городу, исполнитель в другом поясе видит этот же момент по своим часам.

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

Как я это делаю

1. Выясняю, кто получает. Клиенты, сотрудники, партнёры. От этого зависят окна тишины и набор поясов.
2. Завожу пояс в профиле. В мини-приложении из браузера, в боте кнопками, с возможностью править.
3. Храню UTC и имя пояса. Смещения в базу не пишу.
4. Планирую отправку от абсолютного момента. Очередь заданий с проверкой тихих часов перед отправкой.
5. Прогоняю сценарии. День перехода часов, получатель в другом поясе, переезд посреди недели, сообщение в тихие часы. Это ошибки, которые не видны, пока не придёт первое напоминание в три часа ночи.

Напоминания я подключаю к записи, оплате и CRM: смотрите разработку Telegram-ботов. Если бот у вас уже есть, но путает время, могу разобрать его логику и исправить.

Сколько это стоит

Напоминания не продаются отдельной услугой, это часть бота или приложения. Ориентиры по моему прайсу:

• Бот в мессенджере: от 30 000 ₽, от 1 недели.
• Бот для бизнеса с оплатой, записью и CRM: от 80 000 ₽, от 2 недель.
• Онлайн-запись и бронирование с календарём, предоплатой и напоминаниями: от 150 000 ₽, от 3 недель.
• PWA-приложение: от 150 000 ₽, от 1 месяца.
• Поддержка, исправления и доработки: от 20 000 ₽/мес.

Если нужно поправить работу напоминаний в готовом боте, считаю по часам: от 3 000 ₽/час. Точную цену называю после разбора задачи.

Частые вопросы

Почему нельзя просто хранить смещение вроде +03:00?

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

Как узнать часовой пояс пользователя бота?

В мини-приложении можно взять значение из браузера через Intl.DateTimeFormat. В чате бота проще спросить кнопками один раз и дать возможность изменить. Угадывать по номеру телефона ненадёжно.

Что делать, если напоминание попало на ночь?

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

Сколько напоминаний отправлять?

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

Коротко о главном

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

Если нужен бот или мини-приложение с напоминаниями, которые приходят вовремя и не будят людей ночью, напишите мне в Telegram с кодовым словом «ПОЯС»: @chimitdorzhi.