Кратко

  • RFC 867 зафиксировал порт, транспорт и завершение ответа Daytime, но прямо указал, что специального синтаксиса даты нет; два образца были лишь распространёнными вариантами.
  • Для времени, пригодного машине, документ отсылал к отдельному Time Protocol с фиксированным 32-битным значением.
  • История разделяет читаемость и смысловую совместимость: корректная доставка символов ещё не даёт права однозначно преобразовать их в момент времени.

Два правильных ответа без общего разбора

Один сервер пишет Monday, February 22, 1982 17:37:43-PST, другой — 02 FEB 82 07:59:01 PST. Человек узнаёт дату в обеих строках. Программе нужны дополнительные решения: год из двух или четырёх цифр, дефис или пробел перед зоной, обязательность дня недели, язык названий месяцев и приоритет при противоречии полей.

RFC 867 не сделал ни один пример обязательным. Сначала он объявил, что у Daytime нет специального синтаксиса, а затем привёл два популярных способа записи. Парсер одного из них реализует местную договорённость, но не универсальный «формат RFC 867», которого стандарт не создавал.

Транспорт при этом может сработать безупречно. TCP-соединение установлено и закрыто, UDP-ответ доставлен, символы допустимы. Но независимым клиентам не гарантировано одинаковое вычисление момента.

Что именно определяли две страницы

RFC 867 вышел в мае 1983 года и назвал Daytime полезным средством отладки и измерений. В TCP сервер слушал порт 13, после установления соединения отправлял текущие дату и время строкой ASCII, игнорировал полученные данные и закрывался. В UDP любой датаграмме на порт 13 отвечал датаграммой с датой и временем; содержимое запроса не разбиралось.

Рекомендовались печатные символы ASCII, пробел, возврат каретки и перевод строки, а весь ответ должен был занимать одну строку. Этого хватало для прямого просмотра простым инструментом и понятного завершения обмена.

Не задавались порядок полей, разделители, дробная точность, четырёхзначный год, связь с UTC, запись високосной секунды, язык, точность часов и происхождение данных. «Текущее» означало заявление сервера о своих часах, а не сертификат синхронизации. ASCII ограничивал байты, но не неоднозначность календаря.

Регистрация порта тоже не устраняла пробел. Она называла ожидаемую службу, но не делала оператора источником гражданского времени и не придавала буквенной аббревиатуре зоны единственного значения.

Машине предлагалась другая дверь

Последнее примечание RFC 867 направляло машинных потребителей к RFC 868. Time Protocol возвращал на порту 37 беззнаковое 32-битное число секунд с начала 1900 года. Daytime выдавал читаемую строку на 13-м порту, Time — фиксированную величину на 37-м.

Поэтому Daytime неверно считать неудачной сериализацией. Человеческая функция была сознательной. Инженер мог простейшим соединением проверить отклик узла и увидеть часы; вычисляющее приложение выбирало соседний числовой контракт.

RFC 880 в октябре 1983 года отнёс Daytime к elective: хост мог его реализовать или нет. Time получил статус recommended. Историческая категория не показывает нынешнее распространение, но фиксирует различие приоритетов.

У фиксированного числа тоже были ограничения в отображении и последующем контексте эпох. Здесь не повторяется уже опубликованная история NTP и 2036 года; RFC 868 используется только как противопоставление, указанное самим RFC 867.

Пример, споривший сам с собой

Первый пример RFC 867 первоначально называл 22 февраля 1982 года вторником. Это был понедельник. RFC Editor подтвердил erratum 8551 в 2025 году и исправил слово. Это редакционная поправка, не изменение протокола и не свидетельство о реальных серверах.

Тем не менее ошибка точно показывает риск избыточных полей. День недели и полная дата дважды выражают один календарный факт и способны противоречить друг другу. Человек замечает несогласованность; программе нужно правило приоритета. Daytime такого правила не давал, потому что не давал грамматики разбора.

RFC 3339 позднее описал тот же класс проблемы для интернет-меток времени. Он исключил день недели, потребовал четырёхзначный год и явную связь с UTC через числовое смещение или Z, не полагаясь на плохо совместимые буквенные обозначения зон.

Это не цепочка замены. RFC 3339 не отменял RFC 867, а исправление 2025 года не могло вызвать документ 2002 года. Сравнение показывает разное место решения: в Daytime представление выбирает сервер; в RFC 3339 сетевая форма стабильна, а отображение локализует клиент.

Как человеческий вывод становится скрытым API

Читаемость удешевляет отладку, что признаёт и RFC 3339. Но привычный формат одной страны может быть неоднозначным в другой. Глобальный обмен требует отделять форму на проводе от формы на экране.

Пока строку Daytime смотрит человек, свобода полезна. Когда скрипт собирает её, подгоняет регулярное выражение под один сервер и сохраняет только нормализованное значение, пунктуация и слова превращаются в недокументированный API.

Оператор вправе изменить представление и остаться полностью совместимым с RFC 867, а потребитель сломается. Это не нарушение сервера, а результат превращения единичного наблюдения в гарантию, которой стандарт не давал.

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

Регистрация IANA не требует открывать службу

IANA по-прежнему регистрирует daytime для TCP и UDP на порту 13 со ссылкой на RFC 867. Запись сохраняет смысл имени. Она не доказывает развёртывание, точность, безопасность или обязанность публичной доступности.

Версия UDP требует современного эксплуатационного решения. Она отвечает, не разбирая запрос, а исходный IP-адрес можно подделать. RFC 8085 в общем виде предупреждает, что короткие неаутентифицированные запросы с более крупными ответами могут участвовать в усилении, и рекомендует ограничение либо проверку отправителя по ситуации. Источники не измеряют нынешние злоупотребления Daytime.

Вопрос не в том, стандартен ли порт, а в том, зачем он доступен и какой авторитет получает ответ. TCP не аутентифицирует часы, UDP — просителя, а понятный текст — истинность времени.

Ценность границы небольшого стандарта

RFC 867 сделал предсказуемыми подключение, ответ и закрытие, сохранил удобство для глаза и отказался обещать машинную грамматику. Сдержанность была частью конструкции.

Для конкретной наблюдаемой строки можно написать парсер. Но уполномочивает ли стандарт считать, что он переживёт все совместимые серверы и будущие изменения? Для Daytime — нет.

Совместимость многослойна. Порт бывает общим при разной грамматике даты. Символы бывают допустимыми при неоднозначном моменте. Сервер остаётся совместимым, когда автоматизация ломается. Понимать протокол — значит знать и его гарантии, и выводы, которые он сознательно не разрешает.

Источники и пределы доказательств

Правила Daytime находятся в RFC 867, исправление примера — в реестре errata. Машинное противопоставление даёт RFC 868, исторический статус — RFC 880.

RFC 3339 служит позднейшим сравнением; RFC 6335 и реестр IANA ограничивают смысл порта; RFC 8085 — современный UDP. Они не дают нынешней статистики распространения, точности или атак.