Реализация компонента выбора времени и даты для бронирования

При разработке сервиса бронирования для сети медицинских клиник мы обнаружили, что каждый пятый пациент терял бронь из-за бага с часовыми поясами. Сервер хранил все даты в UTC, а фронтенд конвертировал их в локальное время с ошибкой — слоты смещались на час при переходе на летнее время. Аудит показал: 95% проблем приходилось именно на конвертацию. Это типичная история: UI календаря кажется простым, но под капотом требуется синхронизация в реальном времени, учёт часовых поясов и защита от двойного бронирования. Без грамотной архитектуры пользователь видит недоступные слоты или теряет бронь.

Процесс выбора даты и времени

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

function TimeSlotPicker({ resourceId, date, onSelect }: Props) { const { data: slots, isLoading } = useQuery({ queryKey: ['slots', resourceId, format(date, 'yyyy-MM-dd')], queryFn: () => fetchTimeSlots(resourceId, date), }); if (isLoading) return <SlotsSkeleton />; const grouped = groupBy(slots, slot => slot.datetime.getHours() < 13 ? 'morning' : 'afternoon' ); return ( <div className="space-y-4"> {grouped.morning && ( <div> <p className="text-sm text-gray-500 mb-2">Утро</p> <div className="grid grid-cols-4 gap-2"> {grouped.morning.map(slot => ( <button key={slot.id} disabled={!slot.available} onClick={() => onSelect(slot)} className={cn( 'py-2 rounded-lg text-sm border transition', slot.available ? 'border-blue-200 hover:bg-blue-50 hover:border-blue-500' : 'border-gray-100 text-gray-300 cursor-not-allowed' )} > {format(slot.datetime, 'HH:mm')} </button> ))} </div> </div> )} </div> ); } 

Почему часовые пояса — частая причина багов?

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

// Конвертация серверного UTC в локальное время пользователя const localSlot = utcToZonedTime(slot.datetime_utc, userTimezone); const displayTime = format(localSlot, 'HH:mm', { timeZone: userTimezone }); 

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

Как работает защита от двойного бронирования?

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

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

Реализация блокировки на стороне бэкенда с Redis и TTL:

import redis r = redis.Redis() def reserve_slot(slot_id, user_id, ttl=600): key = f"slot:{slot_id}:reserved" if r.setnx(key, user_id): r.expire(key, ttl) return True return False 

Типичные ошибки при реализации:

• Не учитывать переход на летнее время: слоты могут дублироваться или пропадать.
• Хранить временные метки в локальном формате на сервере — всегда используйте UTC.
• Забывать про тайм-ауты блокировки: если пользователь закрыл браузер, слот останется занятым навсегда.

Какой стек технологий мы используем?

Для фронтенда предпочитаем React 18 с TypeScript и date-fns-tz для конвертации часовых поясов. Бэкенд — Laravel 11 или Django 4, база данных — PostgreSQL с Redis для кэширования слотов. Все микросервисы контейнеризированы через Docker.

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

Что входит в работу?

• Разработка календаря с поддержкой диапазонов и исключений
• Бэкенд-логика временных слотов с Redis-кэшом
• API для бронирования с валидацией на сервере (проверка доступности, часовые пояса)
• Документация компонента и схемы данных
• Покрытие кода тестами (unit + интеграционные)
• Инструкция по деплою на сервер

Наш опыт — более 5 лет и 50+ успешно внедрённых проектов. Средняя экономия клиентов на поддержке составляет до 25% за счёт снижения числа инцидентов.

Как мы реализуем конвертацию часовых поясов: пошаговая инструкция

1. На сервере все даты хранятся в UTC, без exceptions.
2. Клиент получает список слотов с полем datetime_utc и временную зону пользователя (из профиля или геолокации).
3. На фронтенде с помощью библиотеки date-fns-tz конвертируем каждую дату в локальную перед отображением.
4. При отправке бронирования передаём slot_id, а не время — сервер сам определяет UTC по ID.

Ориентировочные сроки

Базовая реализация для одного ресурса — 2–3 рабочих дня. Если нужно мультирегиональность, сложная логика повторений и интеграция с внешними системами (например, CRM) — срок может составить до 2 недель. Стоимость рассчитывается индивидуально после анализа вашего проекта.

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