Монотонное время для таймаутов при коррекции UTC
После синхронизации часов таймер ожидания ответа внезапно истёк либо получил лишний запас. Для программного узла телеметрии нужно разделить календарное время события и измерение длительности. Хозяйству важно знать, как приложение ведёт себя при коррекции часов, сне и перезапуске, а не только видеть правильную текущую дату на экране.
Определить смысл интервала
Linux описывает разные часы, включая realtime, monotonic и boottime. (Linux man pages — clock_gettime2) Для своего приложения сначала сформулируйте, должен ли таймаут учитывать время сна системы. Названия шкал не заменяют требования: разные варианты имеют разное поведение, которое нужно сопоставить с реальной задачей ожидания на удалённом шлюзе.
Отдельно сохраняйте календарную отметку для журналов и обмена. Монотонное значение не является UTC датой и не должно превращаться в неё произвольным форматированием. Для сравнения длительностей нужен согласованный источник внутри допустимого жизненного контекста, а для пользовательской хронологии — своё определённое календарное представление.
Проверить кодовый путь ожидания
На учебной конфигурации запишите момент начала, выбранный источник времени и ожидаемый результат. Уточните, что делает библиотека ожидания, а не только пользовательская функция вокруг неё. Если внутренний механизм использует другую шкалу, внешняя правильная отметка не гарантирует нужное поведение всего таймера.
Используйте предусмотренный безопасный способ проверить коррекцию календарных часов либо имитацию источника времени в тесте. Не меняйте рабочие часы диспетчерской ради эксперимента. Сценарий должен быть изолирован от реальных команд управления и действующих расписаний, которые имеют отдельный эксплуатационный календарь хозяйства.
Исследовать сон и перезапуск
Проверьте поддерживаемый режим сна с тем же требованием к сроку ожидания. Если время сна учитывается иначе, чем ожидалось, выберите документированный механизм приложения. Нельзя исправить это простой сменой часового пояса: зона отображения и источник длительности решают разные задачи в системе.
После reboot сохранённая монотонная отметка требует отдельного контракта восстановления. Не сравнивайте её безусловно с новым значением другого жизненного цикла. Для незавершённых операций определите статус и дальнейшее действие, сохраняя различие между продолжением ожидания, просрочкой и неизвестным исходом передачи до перезапуска.
Принять оба вида времени
В журнале храните достаточно сведений для объяснения события и вычисленной длительности. Исходные UTC отметки не перезаписывайте после коррекции. Для пользовательского представления используйте нужную зону, сохраняя при этом реальную шкалу и правила, по которым программа приняла решение о завершении ожидания.
Приёмка подтверждает таймаут при штатной работе, коррекции календарных часов и предусмотренном восстановлении. Для хозяйства это предотвращает ложные отказы и бесконечные ожидания после настройки времени. Правильная дата и правильная длительность становятся разными проверяемыми свойствами приложения сбора и передачи полевых измерений.