Реалізація компонента вибору часу та дати для бронювання

При розробці сервісу бронювання для мережі медичних клінік ми виявили, що кожен п'ятий пацієнт втрачав бронь через баг з часовими поясами. Сервер зберігав всі дати в 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 хвилин. Якщо користувач скасовує або не завершує бронь, блокування знімається. При пікових навантаженнях це надійніше оптимістичного блокування — песимістичне блокування в 2 рази зменшує кількість конфліктів.

У наших проєктах ми обираємо песимістичне для відповідальних ресурсів (наприклад, лікарі, готелі) та оптимістичне для масових подій, де допустимі поодинокі колізії.

Реалізація блокування на стороні бекенда з 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. Наші інженери мають сертифікати AWS та Google Cloud. Ми працюємо з 2019 року, виконали 50+ проєктів, середня економія клієнтів на підтримці — 25% (близько $200–$400/місяць).