DateAndTime в SNMP: отсутствие часового пояса нельзя молча трактовать как UTC
Фотография конкретного исполнения не приложена.
Некоторые MIB передают календарную отметку через DateAndTime. Это последовательность октетов с определённым расположением полей, а не произвольная строка даты. Неправильный разбор способен сдвинуть событие на часы или превратить корректное значение в неверный год.
RFC 2579 определяет длину 8 либо 11 октетов. Короткий вариант содержит локальную дату и время без сведений о часовом поясе. В длинном присутствуют направление и величина смещения от UTC. Отсутствие последних трёх октетов не устанавливает смещение ноль: оно означает, что переданных данных о зоне недостаточно.
Год кодируется двумя октетами в сетевом порядке, а доля секунды — десятыми. Декодер должен учитывать именно эти единицы и длину. Кроме того, определение объекта в конкретной MIB объясняет, к какому событию относится отметка. Успешный разбор формата не доказывает точность календарных часов устройства.
В приёмке проверяют обе длины, положительное и отрицательное смещение, переход даты и десятые доли. Исходные октеты и установленное смещение сохраняют. Для пользовательского отчёта время переводят в согласованную зону отдельным шагом. Если зона не известна из достоверной конфигурации, результат отмечают как неопределённый, сохраняя исходную локальную дату вместо выдуманного UTC-момента.
Основание — Numbered IETF RFC definitions of SNMP, SMIv2, IF-MIB, USM and VACM; references scoped per task, разделы RFC2579 DateAndTime textual convention. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC о SNMP и SMIv2. Они описывают соответствующую модель протокола, а не подтверждённые возможности конкретного агента. Реальные MIB, firmware, права и криптографические реализации устройства не проверялись; сетевые запросы и SET не выполнялись.
