Расписание сдвигается на час: как хранить повторы

Если еженедельная встреча после изменения местного смещения начинается на час раньше или позже, проверьте правило её повторения. «Каждое воскресенье в 09:00 выбранного города» и «через каждые 168 часов после первого запуска» описывают разные задачи. Хранение только первого момента и постоянного интервала может потерять первоначальную договорённость о местных часах.

Ниже используются исторические даты 2024 года и вымышленные события. Примеры вычислены по установленным данным часовых зон Python. Это не прогноз будущих переводов часов и не описание действующего законодательства разных стран. Задача статьи — помочь сформулировать правило планировщика и проверить его на известных переходах, а не предложить универсальный календарный движок.

Сначала спросите, что должно оставаться неизменным

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

Запишите требование без технических сокращений. Например: «встреча начинается в 09:00 по времени Берлина каждое воскресенье». Для другого задания: «между плановыми запусками проходит 168 часов по шкале UTC». Эти формулировки позволяют проверить результат независимо от языка программирования. Не называйте оба варианта просто «раз в неделю», пока участники не договорились о смысле.

Уточните, чья зона задаёт правило. Место события, владелец календаря и устройство просматривающего могут находиться в разных зонах. Отображение времени на телефоне участника не должно незаметно менять исходную договорённость. Пользователь может видеть удобное местное представление, но организатору должно быть понятно, к какому правилу привязана серия.

Что показывает исторический пример с Берлином

Начальная встреча назначена на 24 марта 2024 года, 09:00 в Europe/Berlin. Следующее воскресенье по местному правилу — 31 марта, 09:00. В проверенном наборе данных смещение между этими датами различается. Между соответствующими моментами UTC прошло 167 часов. Если вместо календарного правила прибавить к первому моменту 168 часов в UTC, местные часы покажут 10:00.

Осенний пример даёт обратное расхождение. От 20 октября 2024 года, 09:00 до 27 октября, 09:00 в той же зоне прошло 169 часов. Прибавление фиксированных 168 часов в UTC приводит к 08:00 по местным часам следующего воскресенья. Событие сохранило длительность интервала, но перестало сохранять нужное показание часов.

Для контрольной пары дат 24 и 31 марта 2024 года в Europe/Moscow обе модели дали 09:00 и интервал 168 часов. Это не доказательство равенства моделей вообще. Тест на участке без смены смещения способен скрыть ошибочное правило. Поэтому для календаря нужны примеры, в которых разные трактовки дают разные результаты.

Одного смещения недостаточно для местного правила

Смещение вроде +01:00 описывает отношение конкретного местного времени к UTC. Идентификатор Europe/Berlin позволяет обратиться к набору правил зоны. Для формирования будущих повторов это разные исходные сведения. Если заменить зону одним смещением первого события, планировщик не получит из него полную договорённость о местном календаре.

Документация Python zoneinfo описывает использование данных IANA и работу с переходами смещения. В учебном расчёте эти механизмы применены к историческим датам. Версию среды и использованный файл данных сохранили вместе с результатом. Перенос такого примера в проект требует проверки выбранной библиотеки и доступности подходящих данных, а не ручной таблицы исключений на несколько лет.

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

Повторяющееся местное время может быть неоднозначным

При историческом осеннем переходе в Берлине 27 октября 2024 года локальная отметка 02:30 соответствовала двум разным моментам. В проверке они представлены как 02:30 с +02:00 и 02:30 с +01:00. В UTC это 00:30 и 01:30. Одна запись часов без достаточного контекста не позволяет выбрать нужный момент.

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

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

Перенос одного события не обязан менять всю серию

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

Другой запрос — изменить все следующие встречи на 10:00. Укажите границу действия нового правила и судьбу уже рассчитанных вхождений. Прошедшие события не следует автоматически перезаписывать как будто они всегда начинались иначе. Для будущих записей определите, что нужно пересчитать и какие ранее отправленные сведения потребуется обновить.

Смена зоны серии тоже нуждается в уточнении. Пользователь хочет сохранить местные 09:00 в другом городе или оставить прежние моменты и только посмотреть их иначе? Это разные операции. Хороший экран предлагает понятный выбор по смыслу, а не заставляет угадывать последствия выпадающего списка часовых поясов.

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

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

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

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

Как проверить исправление перед выпуском

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

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