SABSUS / OPERATIONS GUIDEРУКОВОДСТВО ПО ПРОЦЕССАМ
Online booking: time zones and daylight savingОнлайн-запись: часовые пояса и перевод часов
A booking must mean the same appointment to the customer, the branch and the employee, even when their clocks show different dates. Before accepting a booking setup, test what happens when a local hour disappears or occurs twice. The eight cases below turn that requirement into observable results.Запись должна означать один и тот же визит для клиента, объекта и сотрудника, даже если на их часах разные даты. До приёмки системы проверьте, что происходит, когда местный час пропадает или повторяется. Восемь сценариев ниже превращают это требование в наблюдаемые результаты.
Choose which clock defines the promiseКакое время определяет договорённость
For an in-person visit, the branch’s local opening hours usually anchor availability. A remote service may instead follow an agreed staff or customer zone. Make that choice explicit for each service. A customer’s device setting is a display preference, not sufficient evidence that the appointment itself has moved.Для очного визита доступность обычно определяется местным рабочим временем объекта. Для дистанционной услуги основой может быть согласованная зона сотрудника или клиента. Зафиксируйте это для каждой услуги. Настройка устройства клиента определяет отображение, но сама по себе не означает перенос визита.
- Branch: the location and named time zone that define working hours, breaks and unavailable periods.Объект: местоположение и именованная часовая зона, задающие рабочие часы, перерывы и закрытые интервалы.
- Staff: the zone used to enter availability and the branch or remote service to which it applies.Сотрудник: зона, в которой вводится доступность, и объект или дистанционная услуга, к которым она относится.
- Customer: the displayed zone, a way to check or change it, and the visit location or remote joining details.Клиент: отображаемая зона, возможность проверить или изменить её, место визита или условия дистанционного подключения.
Google Calendar displays an event in each invitee’s local zone. That explains why two valid calendar screenshots can show different hours. It does not establish that a booking website, reminder provider or SABSUS connection applies the same rules. Google Calendar time-zone helpGoogle Calendar отображает событие в местной зоне каждого приглашённого. Поэтому два корректных снимка календаря могут показывать разные часы. Это не доказывает, что сайт записи, сервис напоминаний или подключение SABSUS используют те же правила. Справка Google Calendar о часовых поясах
Use the booking rollout checklist to assign schedule ownership and reconcile existing visits.Чек-лист запуска онлайн-записи поможет назначить владельца расписания и сверить существующие визиты.
Keep the zone and the instantСохраните зону и точный момент
Keep a named zone such as Europe/London alongside the agreed local date and time. Once a particular occurrence is resolved, retain its exact instant, commonly represented in UTC. An offset such as UTC+01:00 describes the difference at that instant; it is not a permanent substitute for the zone’s rules.Храните именованную зону, например Europe/London, вместе с согласованными местными датой и временем. После определения конкретного визита сохраняйте его точный момент, обычно в UTC. Смещение UTC+01:00 описывает разницу в этот момент, но не заменяет правила зоны на все будущие даты.
For a weekly service, first decide whether the promise is “09:00 in London every Sunday” or a fixed UTC time. These produce different local schedules around a clock change. Google Calendar’s API requires a single time zone when expanding a recurring event. The intended recurrence, individual exceptions and integration behavior still need acceptance checks. Google Calendar event conceptsДля еженедельной услуги сначала выберите смысл договорённости: «каждое воскресенье в 09:00 по Лондону» или постоянное время UTC. При переводе часов местное расписание будет разным. API Google Calendar требует одну часовую зону для развёртывания повторяющегося события. Правило повторов, отдельные исключения и работу интеграции всё равно нужно проверить. Модель событий Google Calendar
IANA updates its time-zone database as civil-time rules change. Assign someone to check whether the booking system and connected services receive those updates. Review affected future appointments after a rule change; a conversion checked today is not a guarantee for every future year. IANA Time Zone DatabaseIANA обновляет базу часовых зон при изменении правил местного времени. Назначьте ответственного, который проверит получение обновлений системой записи и связанными сервисами. После изменения правил перепроверьте затронутые будущие визиты: расчёт на сегодня не гарантирует тот же результат для любого будущего года. База часовых зон IANA
Eight acceptance casesВосемь проверок приёмки
All appointments below are invented acceptance examples. The UK’s 2026 clock changes are 29 March and 25 October. These dates are specific to the example, not a worldwide DST calendar. Conversions were checked with Python zoneinfo and the cited rules. Run equivalent cases in an isolated test configuration before using them as product evidence. UK clock-change dates · IANA Europe rules · IANA Asia rulesВсе записи ниже придуманы для приёмки. В Великобритании часы переводят 29 марта и 25 октября 2026 года. Эти даты относятся к примеру, а не к мировому календарю DST. Пересчёты проверены в Python zoneinfo и по указанным правилам. Прежде чем считать их доказательством возможностей продукта, выполните аналогичные сценарии в изолированной тестовой конфигурации. Даты перевода часов в Великобритании · Правила IANA для Европы · Правила IANA для Азии
| CaseСлучай | SetupУсловия | Expected observationОжидаемое наблюдение |
|---|---|---|
| 1. Three zones and a new date1. Три зоны и новая дата | A hypothetical remote appointment follows a London branch: 24 October 2026, 17:30 Europe/London. Staff view Europe/Moscow; the customer views Asia/Tokyo.Условная дистанционная запись привязана к объекту в Лондоне: 24 октября 2026, 17:30 Europe/London. Сотрудник видит Europe/Moscow, клиент — Asia/Tokyo. | The same instant is 16:30 UTC, 19:30 Moscow on 24 October and 01:30 Tokyo on 25 October. All views retain one appointment identity; the customer confirmation includes the changed date.Это 16:30 UTC, 19:30 в Москве 24 октября и 01:30 в Токио 25 октября. Во всех представлениях один идентификатор записи; в подтверждении клиенту указана новая дата. |
| 2. Weekly local-time recurrence2. Еженедельный повтор по местному времени | A hypothetical series is agreed for Sundays at 09:00 Europe/London. Compare 18 and 25 October 2026.Условная серия согласована на воскресенья в 09:00 Europe/London. Сравните 18 и 25 октября 2026. | London stays at 09:00. UTC changes from 08:00 to 09:00; Moscow from 11:00 to 12:00; Tokyo from 17:00 to 18:00. Confirm that the series follows the agreed local-time rule.В Лондоне остаётся 09:00. UTC меняется с 08:00 на 09:00, Москва — с 11:00 на 12:00, Токио — с 17:00 на 18:00. Серия должна следовать согласованному правилу местного времени. |
| 3. A local time that does not exist3. Местное время, которого нет | Attempt to select 29 March 2026, 01:30 Europe/London in a controlled test scenario.В контролируемом сценарии проверки выберите 29 марта 2026, 01:30 Europe/London. | This local time is absent during the spring change. Block it or present a valid alternative for explicit agreement. A silent move to another hour fails this acceptance policy.При весеннем переводе часов этого местного времени нет. Оно должно быть недоступно либо заменяться допустимым вариантом с явным согласованием. Незаметный сдвиг на другой час не проходит эту проверку. |
| 4. A local time that occurs twice4. Местное время, которое повторяется | Select 25 October 2026, 01:30 Europe/London. The same displayed hour has two possible instants.Выберите 25 октября 2026, 01:30 Europe/London. Одному времени на часах соответствуют два момента. | The first is 01:30 UTC+01:00 = 00:30 UTC; the second is 01:30 UTC+00:00 = 01:30 UTC. Identify the chosen occurrence in the record and confirmation, or offer an unambiguous alternative.Первый: 01:30 UTC+01:00 = 00:30 UTC; второй: 01:30 UTC+00:00 = 01:30 UTC. Выбранное вхождение должно быть различимо в записи и подтверждении; иначе предложите однозначный вариант. |
| 5. Actual duration across a clock change5. Фактическая длительность при переводе часов | A hypothetical resource is occupied from 00:30 to 02:30 Europe/London on 25 October 2026.Условный ресурс занят с 00:30 до 02:30 Europe/London 25 октября 2026. | The endpoints are 23:30 UTC on 24 October and 02:30 UTC on 25 October: 180 elapsed minutes, although the clock labels differ by two hours. Apply the agreed duration and reset policy to the entire interval.Границы: 23:30 UTC 24 октября и 02:30 UTC 25 октября. Проходит 180 минут, хотя показания часов отличаются на два часа. Правило длительности и подготовки ресурса применяется ко всему интервалу. |
| 6. Moving to the next local day6. Перенос на следующий местный день | Move one hypothetical visit from 24 October 2026 at 09:00 to 25 October at 09:00 Europe/London.Перенесите один условный визит с 24 октября 2026, 09:00, на 25 октября, 09:00 Europe/London. | The UTC values are 24 October 08:00 and 25 October 09:00, 25 hours apart. Recheck staff and resources, leave one current visit and show both the old and revised agreement in its history.Значения UTC: 24 октября 08:00 и 25 октября 09:00; между ними 25 часов. Повторно проверьте сотрудника и ресурсы, оставьте один текущий визит и сохраните прежнюю и новую договорённости в истории. |
| 7. Display-zone change without a reschedule7. Смена отображаемой зоны без переноса | Reopen case 1 with the viewer zone changed from Tokyo to London, without editing the appointment.Снова откройте случай 1, сменив зону просмотра с Токио на Лондон, без редактирования записи. | The display changes from 25 October 01:30 to 24 October 17:30. The instant remains 24 October 16:30 UTC and no reschedule is recorded. Check the visible zone label before confirming.Отображение меняется с 25 октября 01:30 на 24 октября 17:30. Момент остаётся прежним: 24 октября 16:30 UTC; переноса в истории нет. Перед подтверждением проверьте видимую подпись зоны. |
| 8. Reminder meaning and current result8. Смысл напоминания и актуальный результат | For the 25 October 2026 09:00 London visit, compare “24 elapsed hours before” with “09:00 on the previous local day.”Для визита 25 октября 2026 в 09:00 по Лондону сравните «за 24 фактических часа» и «в 09:00 предыдущего местного дня». | The first means 24 October 10:00 London; the second means 24 October 09:00 London, 25 hours before. Check the chosen rule, current visit revision and one intended reminder outcome after rescheduling.Первое означает 24 октября 10:00 по Лондону; второе — 24 октября 09:00, за 25 часов. Проверьте выбранное правило, текущую редакцию визита и один ожидаемый результат напоминания после переноса. |
For each row, collect the customer view, staff view, current record and relevant message preview. Record pass, fail or not supported, plus the owner of any unresolved case. A screenshot showing “01:30” alone cannot distinguish the two occurrences in case 4.Для каждой строки сохраните представление клиента и сотрудника, текущую запись и нужный предпросмотр сообщения. Укажите результат: пройдено, ошибка или не поддерживается, а также ответственного за нерешённый случай. Один снимок с «01:30» не различает два вхождения из случая 4.
Control reschedules and confirmationsКонтролируйте переносы и подтверждения
A confirmation should identify the service, location or remote format, full local date, time and named zone. Around a repeated hour, include enough information to distinguish the chosen occurrence. The customer’s local rendering can be shown alongside the service’s reference zone, with clear labels rather than an unexplained abbreviation.Подтверждение должно определять услугу, место или дистанционный формат, полную местную дату, время и именованную зону. Для повторяющегося часа нужны сведения, различающие выбранное вхождение. Рядом можно показать время клиента и опорную зону услуги, с понятными подписями вместо необъяснённого сокращения.
Treat changing a viewer’s zone, changing a service’s anchor zone and rescheduling an occurrence as separate actions. For a series, state whether the edit affects one visit or future visits. Retain the previous agreement and recheck capacity before accepting the revised time. A sent message and an accepted appointment are separate evidence.Разделяйте смену зоны просмотра, смену опорной зоны услуги и перенос отдельного визита. Для серии укажите, меняется один визит или будущие посещения. Сохраните прежнюю договорённость и повторно проверьте вместимость до принятия нового времени. Отправленное сообщение и принятая запись подтверждают разные события.
Connect the time checks to booking and rescheduling ownership.Свяжите проверки времени с ответственностью за запись и перенос. Check staff capacity and deposit state separately.Отдельно проверьте доступность сотрудников и состояние депозита.
Accept the configured booking pathПринимайте конкретный путь записи
Agree the expected policy before testing, especially for missing hours, repeated hours and recurrence exceptions. If the configuration cannot represent a case reliably, exclude the affected selection and provide a clear supported path. Do not let a receptionist discover the limitation while making a live customer commitment.До проверки согласуйте ожидаемые правила, особенно для пропущенного и двойного часа и исключений серии. Если конфигурация не может надёжно представить случай, исключите соответствующий выбор и предусмотрите понятный поддерживаемый путь. Администратор не должен впервые узнавать об ограничении при договорённости с реальным клиентом.
For a proposed SABSUS setup, verify the selected booking module, calendar integration, zone data, recurrence handling and notification provider together. This guide defines requirements; it does not claim that every calendar edge case is supported natively. Do not send test messages to customers or alter a production calendar to reproduce a DST problem.Для проекта SABSUS совместно проверьте выбранный модуль записи, интеграцию календаря, данные зон, обработку повторов и сервис уведомлений. Это требования к приёмке, а не утверждение о нативной поддержке всех пограничных случаев календаря. Не отправляйте тестовые сообщения клиентам и не меняйте рабочий календарь ради воспроизведения ошибки DST.
Plan the integration evidence and responsibility.Спланируйте доказательства работы интеграции и ответственность. Keep calendar ownership in the handover plan.Включите владельца календаря в план передачи дел.