Как проверить корректность данных календаря?
Что проверяют
Видите ли вы за «датой» всё, что с ней ломается: високосные годы, часовые пояса, повторяющиеся события, локаль. Уточнение часто такое: событие создано в Москве на 10:00, во сколько его увидит коллега в Берлине?
Как отвечать
Сначала уточните, о каком календаре речь: выбор даты в форме или календарь событий. Дальше классы проверок:
- корректность дат: 29 февраля в високосный год (2028) и отказ в обычный, 1900 не високосный, 2000 високосный. Длина месяцев, переход 31 декабря в 1 января и конец месяца;
- локаль: первый день недели (понедельник в России, воскресенье в США), формат
ДД.ММ.ГГГГпротивMM/DD/YYYY, 24 или 12 часов, месяц в родительном падеже («12 марта», а не «12 март»); - номера недель: по ISO 8601 первая неделя та, где первый четверг года. У 2026 года 53 недели, и 53-я захватывает начало 2027, хороший кейс на границу;
- часовые пояса: событие хранится в UTC и показывается в поясе пользователя. Россия на летнее время не переходит, а Европа переходит в последние воскресенья марта и октября: встреча на 02:30 в такой день либо не существует, либо случается дважды. Событие «на весь день» при смене пояса не должно уезжать на соседнюю дату;
- повторения: «каждое 31 число» в феврале, правка одного вхождения против всей серии, удаление серии, исключения. Если есть экспорт, сверьте с правилами
RRULEиз iCalendar; - производственный календарь: праздники и переносы выходных, если продукт считает рабочие дни.
Чтобы гонять пояса, не меняя систему, в Playwright есть опция контекста timezoneId, а в Chrome DevTools пояс переопределяется во вкладке Sensors.
Где спотыкаются
Всё тестируют в одном поясе, совпадающем с сервером. Баги с UTC в таком окружении не видны вообще.
Ограничиваются форматом и «30 февраля», забывая про повторяющиеся события, где ошибок обычно больше всего.
Путают отображение и хранение: проверяют, что на экране 10:00, но не смотрят, что ушло в API и что увидит пользователь в другом поясе.