Задача курса
Валидация интервала времени в FastAPI: задача
Курс «FastAPI для начинающих: API с базой данных и тестами» · урок «Интервал времени в контракте API»
Условие
Проверка времени встречи
Перед бронированием Roomly проверяет предложенный интервал встречи. У начала и конца должен быть указан часовой пояс, а конец должен наступать строго позже начала.
Если интервал корректен, верните обе границы в UTC. Если часового пояса нет или порядок границ нарушен, отклоните данные. В этой задаче проверяется только интервал: искать комнату и сохранять бронирование не нужно.
Что уже дано
Это самостоятельный validation_demo в одном файле. В редакторе есть импорты, пустая BookingIn, app и законченный POST /api/rooms/{room_id}/bookings. Маршрут возвращает room_id и строки starts_at/ends_at через isoformat. Он не ищет комнату, не работает с базой и не заменяет сохраняющий API прежнего проекта.
Готовый публичный переходник выполняет настоящие HTTP-запросы к app через TestClient и передаёт ответы скрытой проверке. Он также читает объявленные поля и сведения о валидаторах BookingIn, не выполняя валидацию вместо модели. Имена ваших методов не фиксированы. Писать этот переходник не требуется.
Что нужно сделать
Реализуйте BookingIn с обязательными starts_at: datetime и ends_at: datetime. Для обоих полей примените field_validator в режиме after: у разобранного значения должно быть смещение от UTC; значение без пояса отклоняется через ValueError. Верните каждый допустимый момент в UTC. Затем model_validator(mode="after") должен отвергнуть равные или обратные границы и вернуть модель при строго более позднем конце. Названия методов и текст ValueError выбираете вы.
Сохраните готовый маршрут. Корректное тело даёт200 и ровно room_id/starts_at/ends_at; обе временные строки равны isoformat нормализованных UTC-значений. Ошибка отдельного поля даёт стандартный422 с loc ["body", "starts_at"] или ["body", "ends_at"]; ошибка отношения двух корректных границ —422 с loc ["body"]. Пропущенные и неверные значения также отклоняются на соответствующем поле. Типизированный room_id берётся из пути, дробный или нечисловой path даёт422. Никакой проверки существования комнаты здесь нет.
Не добавляйте ограничения на дату, длительность или рабочие часы. Дополнительные поля JSON по стандартному поведению BaseModel игнорируются.
Ввод и вывод
stdin не используется. Печатать через print в stdout ничего не нужно. После выполнения файла проверяющая система обращается к верхнеуровневому app: публичный переходник вызывает TestClient внутри процесса приложения и передаёт результат скрытой проверке. Запускать Uvicorn, сеть, клиентский скрипт или pytest не требуется.
Для starts_at="2025-09-01T12:00:00+05:00" и ends_at="2025-09-01T10:00:00+02:00" запрос к /api/rooms/7/bookings возвращает {"room_id":7,"starts_at":"2025-09-01T07:00:00+00:00","ends_at":"2025-09-01T08:00:00+00:00"}. Меньшие часы окончания в исходной строке не означают более ранний момент.
