Port 37: Time Protocol — The Internet's First Clock

Port 37 carries the Time Protocol, one of the oldest and simplest protocols in the Internet's history. When you connect to port 37, you ask the network a single question: What time is it? The server answers with 32 bits representing the number of seconds since midnight on January 1, 1900, then closes the connection. No handshake. No authentication. No conversation. Just time, delivered as a number.

This is the protocol that taught machines to agree on when "now" actually is.

What the Time Protocol Does

The Time Protocol operates on both TCP and UDP over port 37.¹ The mechanism is elegantly minimal:

Over TCP:

1. Client connects to port 37
2. Server immediately sends a 32-bit unsigned integer
3. Both sides close the connection

Over UDP:

1. Client sends an empty datagram to port 37
2. Server responds with a datagram containing the 32-bit time value

That's it. The entire protocol specification fits on a single page. The server doesn't wait for a request format or command. The client doesn't need to identify itself. The moment the connection opens, time flows through.

The 32-bit value represents seconds elapsed since 00:00:00 UTC on January 1, 1900. Some example values from the original specification:¹

To convert this to a usable timestamp, you subtract an offset appropriate for your system's epoch. Unix systems, which count from January 1, 1970, subtract 2,208,988,800 seconds.

The Problem They Were Solving

In the early 1980s, the ARPANET was growing into a network of networks, but the computers on it had a fundamental disagreement: they couldn't agree on what time it was.

Every computer has an internal clock, but clocks drift. Crystal oscillators, the heartbeat of digital timekeeping, run at slightly different rates from machine to machine.² Leave two computers alone for a week, and they might disagree by several seconds. Leave them for a month, and they might differ by minutes.

This wasn't just an inconvenience. It was breaking things.

The Unix make command, which compiles software by checking which source files are newer than their compiled outputs, started producing wrong results when source code lived on a file server with a different clock than the machine doing the compilation.³ Files appeared to have been modified in the future, or the past, depending on which machine you asked.

Logs from different systems couldn't be correlated. Scheduled tasks fired at the wrong times. The network was becoming a collection of machines, each living in its own private timezone of drift.

The solution was obvious: ask someone else what time it is. But in 1983, there was no standard way to do that across the network.

Who Created It

RFC 868 was published in May 1983, authored by two of the Internet's founding architects: Jon Postel and Ken Harrenstien.¹

Jon Postel was, in many ways, the Internet itself. From 1969 until his death in 1998, he served as the RFC Editor, shepherding every technical standard that defined how the network worked. He ran IANA (the Internet Assigned Numbers Authority) from a notebook page where he tracked protocol numbers by hand.⁴ The Economist called him the "God of the Internet," a title he deflected with characteristic humility: "Of course, there isn't any 'God of the Internet.' The Internet works because a lot of people cooperate to do things together."⁴

Postel was instrumental in developing TCP/IP, SMTP, and DNS. He understood that the Internet needed simple, reliable building blocks, and the Time Protocol embodies that philosophy: do one thing, do it simply, and get out of the way.

Ken Harrenstien worked at SRI International's Network Information Center, where he made contributions that echo through the Internet today. He co-created the WHOIS protocol that still lets you look up domain registration information.⁵ In a meeting about the new domain name system, he made a decision that would define online commerce forever: he changed the proposed ".bus" top-level domain to ".com" during implementation "because it seemed like a better choice."⁵

Harrenstien later joined Google, where he worked on automatic closed captioning for online videos. Born deaf, he had loved the early Internet because email and chat let him communicate without a sign language interpreter.⁵ He spent his career making the network accessible to everyone.

These two engineers, working together, created a protocol that asked the simplest possible question: What time is it?

Why January 1, 1900?

The choice of epoch matters. Unix chose January 1, 1970, a date convenient for the engineers working on it in the early 1970s. The Macintosh chose January 1, 1904, a leap year, to simplify date math.⁶

Postel and Harrenstien chose January 1, 1900.

The reasoning was practical: a 32-bit counter can represent about 136 years of seconds. Starting from 1900 meant the protocol could handle dates through 2036, covering most users' lifetimes and reaching comfortably into what felt like the distant future.⁶

The year 1900 also sits at the beginning of the 20th century, a clean psychological boundary. It predates both World Wars, the invention of television, and the digital computer itself. When port 37 tells you the time, it measures from before computers existed.

There's an irony here: 1900 was not actually a leap year. The Gregorian calendar skips leap years on century boundaries unless the year is divisible by 400. This quirk would later cause the famous spreadsheet bug where Lotus 1-2-3, and then Microsoft Excel (for compatibility), incorrectly treats February 29, 1900 as a valid date.⁶ The Time Protocol itself handles this correctly, but the choice of epoch would propagate through decades of software.

The Protocol's Beautiful Simplicity

The Time Protocol has no error correction. No authentication. No encryption. No way to account for network latency. The time you receive is the time when the server sent it, not the time when you received it.

This sounds like a flaw, but it's actually a design philosophy. RFC 868 anticipated that users would "quickly confirm or correct a system's idea of the time, by making a brief poll of several independent sites on the network."¹ The protocol assumes you're smart enough to ask multiple servers and use your judgment.

For early networks, where precision to the nearest second was sufficient and security meant physical access control, this worked beautifully. The rdate command, included in BSD Unix systems, would query an RFC 868 server and set your system clock with a single command.⁷ It was the network equivalent of calling the speaking clock.

The protocol's simplicity also meant it could run as a built-in service of inetd, the Unix "super-server" that listened on multiple ports and spawned the appropriate handler for each connection. Time services required almost no resources: no state to maintain, no sessions to track, no complex parsing. Just a number.

Security: An Artifact of a More Trusting Era

The Time Protocol was designed in 1983, when the ARPANET was a research network connecting universities and military installations. Security meant knowing who had physical access to the building.

By modern standards, the protocol is dangerously naive:⁸

• No authentication: Anyone can run a time server and claim to be authoritative
• No encryption: The time value travels in plaintext
• No integrity checking: A man-in-the-middle can alter the response
• No protection against amplification: UDP responses can be spoofed and directed at victims
• Information leakage: An attacker can probe response timing to learn about server load

Setting a computer's clock incorrectly isn't just an inconvenience. It can invalidate security certificates, break authentication tokens, corrupt log timestamps, and cause cryptographic failures. An attacker who controls your sense of time controls more than you might think.

The SANS Internet Storm Center has documented scanning activity on port 37, though the protocol is now rare enough that such probes typically indicate either legacy systems or reconnaissance.⁹

Modern security guidance is clear: disable port 37 services unless you have a specific legacy requirement, and even then, restrict access to trusted networks.⁸ The protocol that helped bootstrap network timekeeping has become a liability in a hostile Internet.

The Successor: NTP

Two years after RFC 868, David Mills at the University of Delaware published RFC 958, introducing the Network Time Protocol (NTP).¹⁰ Where the Time Protocol was a simple question and answer, NTP was a sophisticated conversation.

NTP accounts for network delay by measuring round-trip time and estimating the path between client and server. It uses multiple servers and distinguishes "truechimers" (reliable sources) from "falsetickers" (sources providing incorrect time).³ It achieves accuracy of milliseconds across the Internet and microseconds on local networks.

NTP uses port 123 and has become one of the Internet's essential invisible services. Every device you own, from smartphones to smart thermostats, uses some form of NTP to stay synchronized.

The Time Protocol faded. The rdate command was superseded by ntpdate and then by always-on NTP daemons.¹⁰ DHCP option 4, which specifies RFC 868 time servers, is essentially unused. As one network engineer put it: "Literally nothing uses this anymore."¹⁰

But port 37 was there first. Before NTP's sophisticated algorithms, before GPS receivers provided nanosecond accuracy, before atomic clocks became available over the network, there was a simple protocol that just told you what time it was.

The 2036 Problem

The Time Protocol's 32-bit counter will overflow on February 7, 2036, at 06:28:16 UTC.¹¹

At that moment, the number of seconds since January 1, 1900 will exceed what 32 bits can represent. The counter will roll over to zero, and any system still trusting RFC 868 will believe it's 1900 again.

This is actually earlier than the more famous Year 2038 problem affecting Unix systems (which use a signed 32-bit counter from 1970 and overflow on January 19, 2038).¹¹ The Time Protocol, by choosing an earlier epoch, hits its limit sooner.

NTPv4 addresses this with a 128-bit timestamp format that won't overflow for billions of years.¹¹ The Time Protocol has no such upgrade path. Its simplicity, once its greatest strength, means there's no way to extend it without breaking the fundamental specification.

But by 2036, the protocol will likely exist only in museum pieces and deeply embedded industrial systems. The countdown to overflow is less a threat than a memorial: a reminder that even the simplest protocols eventually reach their limits.

Related Ports

What Flows Through Port 37

Today, almost nothing flows through port 37. The protocol has been superseded by better alternatives and abandoned by modern systems. The servers that once answered time queries have been retired or firewalled off.

But for a decade, this port carried something essential: consensus. Every query to port 37 was a machine asking its peers to help it understand when "now" actually was. Every response was a gift of shared reality, 32 bits that said "we agree on this moment."

The Time Protocol taught the Internet to synchronize. Before machines could coordinate on anything else, they had to coordinate on time. Before they could agree on transactions or logs or cryptographic proofs, they had to agree on seconds elapsed since an arbitrary moment at the dawn of the 20th century.

Jon Postel and Ken Harrenstien didn't just specify a protocol. They asked a question that every connected system would need to answer: What time is it?

Port 37 was where the Internet learned to share a clock.