До NTP были Time и Daytime: как компьютеры узнавали время в 80-х

Перевод статьи Before NTP there were Time and Daytime — Jeff Geerling.

Собирая демонстрацию NTP на старых «Маках» для выставки VCF Midwest, я наткнулся на RFC 867 и RFC 868 — описания протоколов Daytime и Time соответственно.

Впервые с сетевым временем я столкнулся в 2000 году, когда пересел с подержанного PowerBook 180c на свой первый «новый» компьютер — Power Mac G3. В Mac OS 8.5 Apple добавила в панель управления «Дата и время» пункт «Сетевой сервер времени».

Помню, как дозванивался в интернет по PPP, нажимал кнопку «Установить время сейчас» — и часы компьютера обновлялись. Тогда я не придал этому значения, но это было куда круче, чем сверять наручные часы по телефонной службе точного времени, которая до того была самым точным доступным мне источником.

Но до NTP (RFC 1059, 1988 год) существовал куда более простой способ запросить время у удалённого сервера. В протоколе Time (RFC 868) весь запрос сводился к следующему:

• открыть соединение с сервером на порту 37 (TCP-подключение или пустая UDP-датаграмма);
• получить время в виде 32-битного двоичного числа.

И всё!

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

Но у такой простоты есть обратная сторона — особенно если запрос шёл через интернет с несколькими непредсказуемыми по задержке узлами:

• 32-битное число — это просто «секунды с 00:00 (полночи) 1 января 1900 года по GMT», поэтому лучшее достижимое разрешение — 1 секунда (у NTP 64-битные метки времени, разрешение которых уходит за микросекунды).
• Ни запрос, ни ответ не снабжаются метками времени, так что учесть сетевые задержки или усреднить их со временем невозможно.
• 32-битный счётчик переполнится 7 февраля 2036 года — это «ошибка Y2K36», похожая на юниксовый «эпокалипсис» Y2K38. (У NTP та же проблема, но там для её решения ввели эры.)

Однако в 1983 году, когда вышел RFC, это был просто удобный способ для компьютера в сети получить время от сервера со стабильными часами (у многих машин тогда вообще не было часов реального времени). На нём не строили критичные сервисы вроде распределённых баз данных — тем более что разрешение лучше секунды в вычислительной технике тогда встречалось нечасто (если у вас вообще были точные часы!).

Протокол Daytime (RFC 867) лаконичен, но расплывчат. Он описывает, как вернуть полную дату и время в человекочитаемом виде, например:

Tuesday, February 22, 1982 17:37:43-PST

Расплывчатость — в формате, который оставлен на усмотрение разработчика:

There is no specific syntax for the daytime.  It is recommended that
it be limited to the ASCII printing characters, space, carriage
return, and line feed.  The daytime should be just one line.
    One popular syntax is:
        Weekday, Month Day, Year Time-Zone
        Example:
           Tuesday, February 22, 1982 17:37:43-PST

(«Конкретного синтаксиса для daytime нет. Рекомендуется ограничиться печатными символами ASCII, пробелом, возвратом каретки и переводом строки. Ответ должен занимать одну строку».) Сразу следом предлагается альтернатива dd mmm yy hh:mm:ss zzz — именно она использовалась в SMTP!

Забавный факт: NIST до сих пор поддерживает сервисы RFC 867/868 на time.nist.gov!

$ nc time.nist.gov 13
61281 26-08-29 23:31:43 50 0 0 771.1 UTC(NIST) *

Здесь используется собственный формат ответа, не совпадающий ни с одним из вариантов в RFC:

JJJJJ YR-MO-DA HH:MM:SS TT L H msADV UTC(NIST) OTM

JJJJJ — это модифицированная юлианская дата, а OTM — «метка точного времени» (on-time marker): она означает, что время верно ровно в момент получения… Впрочем, судя по тому, что я нашёл, это скорее «лучшая оценка», которая была полезнее в старых телефонных службах времени¹ — в каком-то смысле более детерминированных.

Определённо, у NIST один из самых странных форматов времени, что я видел!

Оба протокола, Time и Daytime, курировал Джон Постел, которого называли «богом интернета», — он же стоит за такими хитами, как SMTP, IANA и закон Постела.

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

Свой сервер Time и Daytime#

Основательно покопавшись в Time и Daytime, я решил спрятать на своём стенде на VCF Midwest несколько пасхалок — в том числе сервисы Time и Daytime на портах 37 и 13 соответственно.

Если хотите поднять собственный сервер Time/Daytime, в Linux это просто — они встроены в xinetd. Инструкция ниже для Pi OS / Debian, но в других дистрибутивах всё похоже:

# Установить и включить xinetd
sudo apt install xinetd
sudo systemctl enable xinetd
# Отредактировать конфигурации time и daytime
sudo nano /etc/xinetd.d/time
  -> service time tcp set disable to "no"
  -> service time udp set disable to "no"
sudo nano /etc/xinetd.d/daytime
  -> service daytime tcp set disable to "no"
  -> service daytime udp set disable to "no"
# Перезапустить xinetd
sudo systemctl restart xinetd

Убедитесь, что порты 37 и 13 открыты в файрволе, а затем проверьте с другого компьютера в сети:

# Time
$ nc 10.0.37.60 37 | xxd -g 1
00000000: ee 3f 24 b3                                      .?$.
# Проверяем значение Time, передав его в `date`:
$ date -r $(( 0xee3f24c8 - 2208988800 ))
Sun Aug 30 16:53:12 CDT 2026
# Daytime
$ nc -v 10.0.37.60 13
Connection to 10.0.37.60 port 13 [tcp/daytime] succeeded!
30 AUG 2026 16:49:26 CDT

Число 2208988800 в команде date выше — это разница в секундах между 1900 и 1970 годами. Она нужна, потому что эпоха UNIX-времени начинается в 1970 году, а у Time и NTP — в 1900-м.

Если будете на VCF Midwest — особенно с ретрокомпьютером, подключённым к сети выставки, — могу угостить вас точным Time. Или Daytime, если угодно!