Краткий ответ

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

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

Исторический контекст

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

Для измерения интервалов в операционных системах появились монотонные часы. Их значение не откатывается при изменении календарного времени, поэтому они подходят для таймеров, тайм-аутов и расчёта длительности операций.

Постановка проблемы

В приведённом коде начало и конец интервала берутся из wallClock. Если пользователь переведёт часы на час вперёд, приложение может немедленно посчитать, что пять минут уже прошли. Если часы перевести назад, выход из сессии может задержаться.

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

Подробное решение

Для локального измерения интервала нужно сохранить значение монотонных часов при входе и сравнивать его с текущим монотонным значением:

startedAt = monotonicClock.now()

while session.isActive:
    elapsed = monotonicClock.now() - startedAt
    if elapsed >= 5 minutes:
        session.logout()

Монотонные часы измеряют прошедшее время независимо от календарной даты. На мобильных платформах нужно выбирать системный источник, предназначенный для elapsed time или monotonic time, а не форматированную дату и не локальное время пользователя.

Это решение не означает, что монотонные часы подходят для всех задач. Срок действия JWT, сертификата или серверной сессии сравнивается с абсолютным временем, обычно полученным от сервера; локальный монотонный счётчик не может заменить такую проверку после перезапуска приложения.

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

Ситуация из практики

В приложении для подтверждения операции был установлен локальный тайм-аут в 60 секунд. На части устройств пользователь после автоматической синхронизации времени получал сообщение «время истекло» почти сразу после открытия экрана.

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

Выбрали второй вариант: монотонный источник использовали для 60-секундного интерфейсного тайм-аута, а сервер оставили источником истины для действительности операции. После этого ручная смена времени и синхронизация перестали преждевременно завершать локальный отсчёт; отдельно были добавлены тесты восстановления экрана и повторной проверки операции на сервере.

Что кандидаты часто упускают

Вопрос: Что произойдёт с монотонным таймером после перезапуска приложения?

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

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

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