Кратко

  • RFC 868 определила 32-битное число секунд с 1 января 1900 года, которое сервер возвращал по TCP или UDP через порт 37.
  • Граница 2036 года была указана в стандарте с самого начала. Точный момент переполнения вычисляется по ширине поля, но RFC называет только год.
  • NTP вырос из службы одного временного отсчёта в систему синхронизации часов, где нужно также определить эпоху значения.

Одно число для сверки часов

В 1983 году не у каждой системы были календарные часы, а человеческая или машинная ошибка могла исказить любые показания. RFC 868 предлагала быстро опрашивать несколько независимых узлов и сравнивать ответы. Она задавала общий формат для машинного чтения, а не полный алгоритм синхронизации.

Число считало секунды от полуночи GMT 1 января 1900 года. Сервер слушал порт 37. При TCP клиент подключался, получал двоичное значение из 32 бит, и сервер закрывал соединение. При UDP клиент отправлял пустую дейтаграмму и получал ответ с числом. Если сервер не мог узнать своё время, ему следовало не подменять ответ: отказать или закрыть TCP без значения либо промолчать на UDP-запрос.

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

Текстовый сервис и машинный формат

Опубликованная в том же месяце RFC 867 Daytime отправляла ASCII-строку с датой и временем через порт 13, например для отладки и измерений. Она рекомендовала печатные знаки, но не фиксировала формат строки; для машинного использования примечание указывало на RFC 868. Это различие способов представления, а не свидетельство об одинаковом качестве серверных часов.

Эпоха 1900 года предшествовала привычному началу Unix-времени в 1970-м. RFC 868 приводит пример пересчёта: 00:00 GMT 1 января 1970 года соответствует числу 2 208 988 800. Общий начальный момент позволяет сравнивать показания, если совпадают единицы измерения.

Короткое поле имело обозначенный срок. RFC 868 говорила, что эта база прослужит «до 2036 года». Беззнаковый счётчик из 32 бит достигает 2³² секунд 7 февраля 2036 года в 06:28:16 GMT. Это результат расчёта по эпохе и ширине поля; сама RFC указывает только год. Следующая секунда выходит за диапазон, поэтому число возвращается к нулю. Без даты из другого источника одинаковые значения до и после переполнения можно перепутать.

NTP решал задачу синхронизации

В 1985 году RFC 958 описала NTP как развитие RFC 868 и сообщения ICMP Timestamp, подходящее на замену обоим. NTP предназначался для синхронизации нескольких сетевых часов распределёнными клиентами и серверами, а не для одной выдачи времени.

NTP сохранил эпоху 1900 года, но добавил работу с эпохами счётчика. Поздняя RFC 5905 объясняет 32-битное поле секунд и переход от эпохи 0 к эпохе 1 в 2036-м. В передаваемой отметке есть и дробная часть, однако определение полной эпохи зависит от контекста. Примерное знание текущей даты помогает правильно прочитать значение около переполнения.

Так компактный формат не стал вечным. RFC 868 облегчила запрос и обозначила горизонт выбранной основы. NTP принял на себя более широкие задачи синхронизации и определения эпохи. Граница присутствовала в стандарте уже в 1983 году: число начиналось с 1900-го, но само по себе не могло бесконечно объяснять, к какому периоду относится.

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

Основной источник — RFC 868, Time Protocol, май 1983 года. RFC 867 показывает текстовую альтернативу, RFC 958 фиксирует заявленную связь NTP с предшественниками, RFC 5905 объясняет позднюю обработку эпох. Эти документы не устанавливают число серверов RFC 868, точность их показаний, всеобщий переход или аварию в 2036 году.

RFC 2626 также отмечает переполнение в 2036 году, однако указанная там точная минута расходится с расчётом выше. Поэтому здесь этот документ подтверждает лишь то, что о границе года предупреждали, но не точное время (RFC 2626). Note 65 Хэнга Лу помогла сформулировать редакционный вопрос о том, как реализации продолжают действие письменного правила; это оптика анализа, а не историческое свидетельство (Note 65).